[whatwg] PaceEntryMediatype

[Thomas Broyer]

2006/11/30, Mark Baker:
>
> 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.

Yes.

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

-1
This means RSS would need two media types.
This also means an HTML document can be a "feed", or it needs its own
media type.
In an "entry" page in a blog-like scenario, we could find:
   <link rel="feed" href="/feed.atom" type="application/atom+xml;type=feed">
   <link rel="feed" href="/" type="text/html">
which tells you the page "believes" it is an "item" in the linked "feeds".
Then , in /feed.atom:
    <atom:link rel="alternate" href="/" type="text/html" />
and in the "/":
    <link rel="alternate" href="/feed.atom"
type="application/atom+xml;type=feed">

And yes, HTML pages are "subscribable", either using a microformat
(see the W3C's home page, from which the RSS is actually produced
using an XSLT stylesheet), or using user-defined "scrapping" (some
aggregators allow you to subscribe to any web page; they try to infer
the "entries" from the semantical markup –h1, h2, h3, etc.– and you
can customize the mechanism in per-feed basis: this page uses h2, this
one uses h3 with class="article", etc.)

The relation from the "entry" page to the feed or "home page" is the
same (hey, they are alternates!): they are "feeds", whatever their
representation (Atom, RSS, HTML, etc.)
The difference with "container"? a "feed" is known to have a
representation which only exposes a subset of the contained items.

This is the same as:
<link rel="contents" href="/toc.html" type="text/html">
<link rel="contents" href="/toc.opml" type="what's the media type for OPML?">

> Another way forward, because the rel="feed" inference is triggered not
> just by the media type but by the "alternate" relationship keyword, is
> to create a non-feed alternate relationship ("alternate-non-feed"?
> ick).
>
> I prefer the new relationship to a new media type because it's less
> disruptive; it doesn't require futzing around with existing specs and
> implementations.

I'd prefer basing autodiscovery on the media types and not at all on
the relationships. A "feed" relationship would only help finding the
"living resource" (similar to rel="current" in the Atom Relationship
Registry) if you're not already "on" it (in which case,
rel="alternate" would be used).

UAs would then obviously continue to support autodiscovery using
"alternate" all-over-the-place, this would just be a lucky
side-effect; and everyone would be happy.

-- 
Thomas Broyer