[whatwg] PaceEntryMediatype

[fantasai]

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
   application/atom.entry+xml
or
   application/atom+xml;type=entry

It also won't be implied on an Atom feed document if the syntax
   application/atom+xml;type=feed
or
   application/atom+xml;type=archive
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).

~fantasai