Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
2006/11/29, James M Snell: The problem I have with the WHAT-WG definition of the alternate and feed relations is the unintended conflict that occurs when the alternate representation of a page happens to be an Atom Entry Document. The HTML5 draft says, If the alternate keyword is used with the type attribute set to the value application/rss+xml or the value application/atom+xml, then the user agent must treat the link as it would if it had the feed keyword specified as well. It goes on to say, The feed keyword indicates that the referenced document is a syndication feed. If the alternate link type is also specified, then the feed is specifically the feed for the current document The problem with this is that the application/atom+xml media type is also used for Atom Entry Documents: link rel=alternate type=application/atom+xml href=entry.xml / The current WHAT-WG definition is inadequate. Already exposed here: http://www.imc.org/atom-syntax/mail-archive/msg19100.html and there: http://www.imc.org/atom-syntax/mail-archive/msg19107.html ;-) There are three possible solutions: 1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom media type is addressed +1 (see above; see also Mark Baker's mail in this same thread –not yet in the archives) 2. We add a type parameter to the application/atom+xml media type to differentiate feed and entry documents, e.g. application/atom+xml;type=feed, application/atom+xml;type=entry +1 When the media type is used without the type parameter, type=feed is assumed. I'd rather say: if there's no 'type' parameter, assume nothing, it can be a feed or entry; this would make the updated media-type fully backwards compatible with the current one (which shipped a year ago). 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml -1 -- Thomas Broyer
RE: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
I would like to have application/atomentry+xml for entry. As a result, application/atom+xml must be a feed. 2. We add a type parameter to the application/atom+xml media type to differentiate feed and entry documents, e.g. application/atom+xml;type=feed, application/atom+xml;type=entry When the media type is used without the type parameter, type=feed is assumed. This cause is ok, but a bit complicated. We have already had a charset parameter. If using both the type and the charset parameters together, then the Content-Type header will be application/atom+xml; type=feed; charset=utf-8. If type parameter is not declared, then type=feed is assumed because most feeds are serving with application/atom+xml with or without the charset parameter today. Franklin Tse -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Broyer Sent: Wednesday, November 29, 2006 16:04 To: Atom-Syntax Subject: Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless) 2006/11/29, James M Snell: The problem I have with the WHAT-WG definition of the alternate and feed relations is the unintended conflict that occurs when the alternate representation of a page happens to be an Atom Entry Document. The HTML5 draft says, If the alternate keyword is used with the type attribute set to the value application/rss+xml or the value application/atom+xml, then the user agent must treat the link as it would if it had the feed keyword specified as well. It goes on to say, The feed keyword indicates that the referenced document is a syndication feed. If the alternate link type is also specified, then the feed is specifically the feed for the current document The problem with this is that the application/atom+xml media type is also used for Atom Entry Documents: link rel=alternate type=application/atom+xml href=entry.xml / The current WHAT-WG definition is inadequate. Already exposed here: http://www.imc.org/atom-syntax/mail-archive/msg19100.html and there: http://www.imc.org/atom-syntax/mail-archive/msg19107.html ;-) There are three possible solutions: 1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom media type is addressed +1 (see above; see also Mark Baker's mail in this same thread –not yet in the archives) 2. We add a type parameter to the application/atom+xml media type to differentiate feed and entry documents, e.g. application/atom+xml;type=feed, application/atom+xml;type=entry +1 When the media type is used without the type parameter, type=feed is assumed. I'd rather say: if there's no 'type' parameter, assume nothing, it can be a feed or entry; this would make the updated media-type fully backwards compatible with the current one (which shipped a year ago). 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml -1 -- Thomas Broyer
WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
The problem I have with the WHAT-WG definition of the alternate and feed relations is the unintended conflict that occurs when the alternate representation of a page happens to be an Atom Entry Document. The HTML5 draft says, If the alternate keyword is used with the type attribute set to the value application/rss+xml or the value application/atom+xml, then the user agent must treat the link as it would if it had the feed keyword specified as well. It goes on to say, The feed keyword indicates that the referenced document is a syndication feed. If the alternate link type is also specified, then the feed is specifically the feed for the current document The problem with this is that the application/atom+xml media type is also used for Atom Entry Documents: link rel=alternate type=application/atom+xml href=entry.xml / The current WHAT-WG definition is inadequate. There are three possible solutions: 1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom media type is addressed 2. We add a type parameter to the application/atom+xml media type to differentiate feed and entry documents, e.g. application/atom+xml;type=feed, application/atom+xml;type=entry When the media type is used without the type parameter, type=feed is assumed. 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml Given that there are significantly fewer instances of Atom Entry Documents that would need to be updated and the fact that the ambiguity in the Atom media type has come up as a problem before, I'd actually lean strongly in favor of options 2 or 3. - James Henri Sivonen wrote: On Nov 28, 2006, at 22:11, Edward O'Connor wrote: WHAT WG seems like a neutral ground, syndication-format wise, so perhaps they're best positioned to spec feed autodiscovery in a way that makes everybody happy. +1 for leaving speccing this to the WHATWG. --Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote: 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml No one relies on Atom Entry alternates now, so this is the best option. We should tack it onto the APP draft, since that will solve issues with the accept element there. And praise to mnot, who suggested we do this in RFC4287 but was overruled by the WG (including myself). -- Robert Sayre
Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
* James M Snell [EMAIL PROTECTED] [2006-11-29 00:20]: 3. We define a new media type for Atom Entry Documents, e.g. application/atomentry+xml +1 * Robert Sayre [EMAIL PROTECTED] [2006-11-29 00:40]: We should tack it onto the APP draft, since that will solve issues with the accept element there. And praise to mnot, who suggested we do this in RFC4287 but was overruled by the WG (including myself). +1 (Wow, I +1ed both James and Robert in the same mail. :-) ) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote: There are three possible solutions: 1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom media type is addressed What ambiguity? There's no ambiguity AFAICT. But the WHAT spec does need fixing. Assuming rel=feed because of the value of a (non-authoritative!) media type conflates two independent concepts, and as a result may confuse users who are looking for syndication feeds but instead find themselves confronted with non-traditional (non-feed) Atom documents. If that's fixed, then this should work fine for entries (assuming alternate semantics); link rel=alternate type=application/atom+xml href=foo.atom / There's no need for a new media type. Mark.
