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
