[whatwg] PaceEntryMediatype

fantasai fantasai.lists at inkedblade.net
Wed Dec 6 00:18:07 PST 2006

Mark Baker wrote:
> The real problem here AIUI - at least in the context of HTML 5's
> inferred rel="feed" bit - is not just entry documents, it's any Atom
> document which wouldn't normally be considered a "feed" by a typical
> user; something that most people would be interested in subscribing
> to.  An example I gave on the whatwg list was an MHTML-like (MIME
> multipart) package, but there are many other possible examples of
> course; not all RFC 4287 feed documents are "feeds" in this sense.
> If HTML 5 (and current practice) doesn't change, but we defer to them
> for the specification of autodiscovery, then a new media type would be
> one way forward.  But it should be reusable for all non-"feed" (i.e.
> from a user POV, as above) Atom documents, not just entry documents;
> perhaps application/atom-no-feed+xml.  It's an ugly hack, but it's
> better than the alternative of many more specific Atom-related media
> types, which atomentry+xml might set a precedent for.

Note that HTML 5's special handling of alternate+Atom is triggered on a
literal value for the 'type' attribute:

  # 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.

That means rel="feed" won't be implied on an Atom Entry document whether the
new MIME type syntax is chosen to be

It also won't be implied on an Atom feed document if the syntax
is used, as was suggested earlier. This gives us a way to say
   <link rel="alternate" href="[..]" type="[atom]">
without implying
   <link rel="alternate feed" href="[..]" type="[atom]">
and without dropping the 'type' attribute entirely (which was the other
solution pointed out on the whatwg list).


More information about the whatwg mailing list