Re: base within HTML content
On Tue, 02 Jan 2007 01:21:09 +0100, Henri Sivonen [EMAIL PROTECTED] wrote: I suppose you could raise this on the WHATWG list. Asking what happens if you set innerHTML of a div where the setted value has both a base and an a for instance. Interesting. I hadn't thought that Atom was supposed to use innerHTML parsing. I'd have said that you prepend !DOCTYPE htmltitle/ titlediv to what travels in the feed and append /div to it, parse the resulting string and grab the first div in the document order. That could work as well. In that case base would most certainly apply. But nothing like that is defined... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: base within HTML content
* Henri Sivonen [EMAIL PROTECTED] [2007-01-02 01:35]: I hadn't thought that Atom was supposed to use innerHTML parsing. I'd have said that you prepend !DOCTYPE htmltitle/titlediv to what travels in the feed and append /div to it, parse the resulting string and grab the first div in the document order. That will lead to silent data loss if the content is malformed such that it contains an extraneous `/div`. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: base within HTML content
On Tue, 02 Jan 2007 02:12:14 +0100, James Holderness [EMAIL PROTECTED] wrote: Well that's not really what I've learnt. I've learnt that there are a lot of broken feeds out there (Atom as well as RSS) and that users are less than impressed when you tell them it's not your fault and they should complain to someone else. So if a feed is non-well-formed you should just parse it as well using some tag soup parser for XML? I don't necessarily disagree with that, but I'd like error handling to be defined in great detail. Everyone just doing what is best for their users will lead you to where HTML is now (at best). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: base within HTML content
On Tue, 02 Jan 2007 11:40:53 +0100, A. Pagaltzis [EMAIL PROTECTED] wrote: * Henri Sivonen [EMAIL PROTECTED] [2007-01-02 01:35]: I hadn't thought that Atom was supposed to use innerHTML parsing. I'd have said that you prepend !DOCTYPE htmltitle/titlediv to what travels in the feed and append /div to it, parse the resulting string and grab the first div in the document order. That will lead to silent data loss if the content is malformed such that it contains an extraneous `/div`. Yeah, it's probably better to take the first and only body element. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: base within HTML content
On Jan 2, 2007, at 12:40, A. Pagaltzis wrote: * Henri Sivonen [EMAIL PROTECTED] [2007-01-02 01:35]: I hadn't thought that Atom was supposed to use innerHTML parsing. I'd have said that you prepend !DOCTYPE htmltitle/titlediv to what travels in the feed and append /div to it, parse the resulting string and grab the first div in the document order. That will lead to silent data loss if the content is malformed such that it contains an extraneous `/div`. Good point. Prepending !DOCTYPE htmltitle/title and grabbing the contents of body would work better. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: base within HTML content
Anne van Kesteren wrote: So if a feed is non-well-formed you should just parse it as well using some tag soup parser for XML? Well that's what I do. The Google Reader blog post I quoted estimated that about seven percent of feeds contained XML errors of some kind. That's a lot of feeds for me to ignore. I'm sure other aggregator authors will choose otherwise. It just depends on their needs and the needs of their users. I'd like error handling to be defined in great detail. Everyone just doing what is best for their users will lead you to where HTML is now (at best). To be honest, I don't care. I'm not trying to make policy here. I was just offering my advice to one particular person in response to one particular query. Regards James
I-D ACTION:draft-ietf-atompub-typeparam-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The application/atom+xml Type Parameter Author(s) : J. Snell Filename: draft-ietf-atompub-typeparam-00.txt Pages : 6 Date: 2007-1-2 The Atom Syndication Format (RFC 4287) defines the 'application/ atom+xml' media type to identify both Atom Feed and Atom Entry Documents. This document defines an optional 'type' parameter used to differentiate the two types of Atom documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-typeparam-00.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-ietf-atompub-typeparam-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-ietf-atompub-typeparam-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-atompub-typeparam-00.txt
Re: I-D ACTION:draft-ietf-atompub-typeparam-00.txt
This document looks good on an initial quick read -- with one possible exception. It says: Atom processors that do recognize the parameter SHOULD detect and report inconsistencies between the parameter's value and the actual type of the document's root element. This would seem to be creating a directive concerning behavior which is not directly related to interoperation between systems. (I'm assuming that the destination of the reports is the user of the application, a log file, or something like that.) Thus, it seems to me that it might be inappropriate to use the SHOULD word since IETF apps are supposed to be focused on interoperation and are supposed to avoid constraining application behavior unnecessarily. May I suggest that you rewrite this sentence in a manner similar to that below: It is strongly recommended that Atom processors that do recognize the parameter detect and report bob wyman
