[whatwg] PaceEntryMediatype

[Thomas Broyer]

2006/12/1, Ian Hickson:
> On Fri, 1 Dec 2006, Thomas Broyer wrote:
> >
> > A summary of my problem with HTML5's autodiscovery:
> > - there shouldn't be a 'rel' value for "subscribability",
> > subscribability is a matter of whether and how an UA can process
> > content from a particular media type
>
> Agreed. The spec doesn't mention subscribing, just that rel=feed means
> it's a syndication feed.

And what is a "syndication feed", if not something that's "subscribable"?

I mean, there is no definition of "syndication feed", neither of "feed
autodiscovery" (what's the purpose of "feed autodiscovery", if not to
subscribe to such feeds?)

In that sense, I really do think the spec is mentionning subscribing.

> > - HTML5 shouldn't say anything about which media type is
> > "subscribable": application/atom+xml can be an Atom Entry, and there
> > might be other subscribable media types (some aggregators allow you to
> > subscribe to HTML); in other words, there shouldn't be any assumption
> > of subscribability *from within the spec*.
>
> Agreed, within the constraints of backwards compatibility. While it
> doesn't mention subscribing to them, there are two explicit values for the
> type="" attribute which have been grandfathered into meaning rel=feed.
> This is needed for compatibility with existing content and existing UAs,
> and isn't something that we have any ability to change, given the
> widespread use of these types for that purpose.

With my "proposal", existing content would still be found by "feed
autodiscovery", it would just be "semantically incorrect" in many
cases (from an "entry" page, when linking to the feed containing the
entry with rel="alternate"; the feed is not an alternate to the entry;
the use of rel="alternate" was just a hack to "display the orange
icon").

As for existing UAs, HTML5 adds a new rel="feed" to try to "fix" this
semantically incorrect existing markup, so existing UAs won't catch
those feeds. My opinion is that the curent definition of rel="feed" is
"bad", and the attempt of widening the feed autodiscovery algorithm is
also badly defined.

Example:
When you open an Atom feed in Firefox 2 or IE7 (and probably other
browsers too), the browsers gives a way to subscribe to the feed. Why
is it doing it? because it believes this is a "subscribable resource".
Why is it believing it? because the media type is know to be one of a
"potentially subscribable" resource.
When you include a <link> element in an HTML page, you're describing a
relationship with another resource. If you give the media-type of this
resource and it is known to be one of a "potentially subscribable"
resource, the browser you help you subscribe to it, whichever the
relationship with the current page (alternate, up, etc.)
The relationship should help in understanding why the other resource
has been linked and what it means relative to the current page; i.e.
it should help in how to *display* the "subscribe to..."
link/button/menu/etc. ("subscribe to this page" –rel="alternate"–,
"subscribe to news on this site" –rel="XXX"–, etc.) The title
attribute is additional guidance for the user to choose whether he'll
want to subscribe.

Now, there also is a need to link from an 'item' to the 'containing
feed', because weblog authors often want to "provide autodiscovery"
for their site-wide feed from within "entry-level" pages.
Here comes the "feed" relationship in my "model", it really deals with
the relationship between the resources, and this relationship implies
"subscribability" (I –the entry– am part of a "feed of entries" which
you can find here; where "feed of entries" implies subscribability).
The definition of "feed" here is: a container of "items" whose
representation generally only exposes the most recently added and/or
updated items.

HTML5 adds an <article> element. If an HTML5 page contains such an
element (and a priori more than one), it might mean that the page is
kind of a "feed" (see the W3C's homepage, or almost any blog's
homepage) and can be subscribed. There's no reason HTML5-aware UAs
couldn't propose a "subscribe to this page" mechanism, infering
"article metadata" from semantic markup (headings, <cite>, <time>, <a
rel="tag">, etc.)
Using a rel="feed" relationship as described above (which I believe is
*not* the one of the current WA1 draft), it is then also possible to
link from the "entry-level" page to the "feed" page:
   <link rel="feed" type="text/html" href="/index.html">
UAs could then display a "(try to) subscribe to this site" link/button/etc.

Actually, after reading WA1 a bit closer, rel="index" could be
sufficient; there wouldn't even be a need for a new relationship.

> > - rel="feed" could be useful, but as a real relationship between
> > resources (the resource pointed to by a rel="feed" link is a 'feed' in
> > which the "current" resource "believes" it appears or has appeared as a
> > contained item), not as defined currently in HTML5.
>
> It sounds like you're describing rel="feed alternate", which is a
> syndication feed explicitly for the current document, as opposed to a
> rel=feed on its own, which is a syndication feed for any random subject.

I was describing something as in the blog scenario above. It seems I
was describing rel="index".

> > Actually my main problems are:
> > - the definition of rel="feed"
>
> It's not clear to me what you think needs changing. Could you suggest an
> explicit set of changes that would satisfy you?

<q cite="http://www.whatwg.org/specs/web-apps/current-work/#feed0">
The feed keyword indicates that the referenced document is a syndication feed.
</q>

This means the 'feed' "relationship" defines what *is* at the other
end of the link, not in what it *relates* to the current resource. It
does not defines a "relationship", it basically says there is one
(otherwise there wouldn't be a <link>), without saying which one (is
it a feed where the current resource appear as an 'item'? is it "just
a related feed"? if so, why isn't there a rel="related" for other,
non-feed, resources?)

<q cite="http://www.whatwg.org/specs/web-apps/current-work/#feed0">
If the alternate link type is also specified, then the feed is
specifically the feed for the current document;</q>

rel="alternate" and type="" are enough:
 - type="" gives you (the UA) enough information about whether you are
able to subscribe to it, thus whether you will show a "subscribe
to..." for this <link>;
 - rel="alternate" tells you it is an alternate representation of the
current page, so you know you can display a "...this page"
 - title="" brings some more guidance for the user to choose between
"potentially subscribable resources" in case there are more than one
(i.e. more than one <link rel="alternate"> in this case)

For example, given the following links:
<link rel="alternate" type="application/atom+xml"
      title="This page as an Atom Entry Document" href="/entry1.atom">
<link rel="alternate" type="application/atom+xml"
      title="Comments on this article" href="/entry1-comments.atom">
<link rel="alternate" type="application/rss+xml"
      title="Comments on this article" href="/entry1-comments.xml">
<link rel="index" type="application/atom+xml"
      title="My wonderful blog" href="/feed.atom">
<link rel="index" type="application/rss+xml"
      title="My wonderful blog" href="/feed.xml">
<link rel="tag" type="application/atom+xml"
      title="Articles in the 'Foo' category" href="/foo.atom">
<link rel="tag" type="application/atom+xml"
      title="Articles in the 'Bar' category" href="/bar.atom">

You could provide this kind of menu (expressed as an HTML list of options):
<menu label="Subscribe to..." type="popup">
   <optgroup label="This page">
      <option label="This page as an Atom Entry Document"
              value="http://example.org/entry1.atom">
      <option Label="Comments on this article (Atom)"
              value="/entry1-comments.atom">
      <option Label="Comments on this article (RSS)"
              value="/entry1-comments.xml">
   </optgroup>
   <optgroup label="This site">
      <option label="My wonderful blog (Atom)"
              value="http://example.org/feed.atom">
      <option label="My wonderful blog (RSS)"
              value="http://example.org/feed.xml">
   </optgroup>
   <optgroup label="Tags">
      <option label="Articles in the 'Foo' category"
              value="http://example.org/foo.atom">
      <option label="Articles in the 'Bar' category"
              value="http://example.org/bar.xml">
   </optgroup>
</menu>


<q cite="http://www.whatwg.org/specs/web-apps/current-work/#feed0">
otherwise, the feed is just a syndication feed, not necessarily
associated with a particular Web page.</q>

If you use a <link>, you're defining/describing a relationship between
two resources. This means the linked feed is somehow associated with
the linking page. How then can it be "just a syndication feed, not
necessarily associated with a particular Web page"?
It might be just a problem with the wording…

> > - the assumption that rel="alternate"+Atom or rel="alternate"+RSS is
> > equivalent to rel="feed alternate"
>
> This is out of our hands, sadly. There are literally hundreds of millions
> of deployed <link> elements that make those assumptions today. We can't
> break legacy UAs and documents.

Deployed <link> elements use rel="alternate" as a "hack" because
current autodiscovery code relies on this particular value. Given my
"proposal", such <link>s would still be "discovered", just that
they'll be shown in the "This page" section of the "subscription menu"
in the example above, instead of the "This site" section. But it's a
problem with authors, due to a too "narrow" autodiscovery algorithm,
it's not a problem with HTML and HTML5 shouldn't do anything about it
(apart from ensuring they'll still be discovered).

<q cite="http://www.whatwg.org/specs/web-apps/current-work/#alternate0">
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.</q>

This goes against the definition of rel="alternate" in the next
sentence, in 90% of the hunderds of millions of <link> elements using
rel="alternate" for feed autodiscovery:
<q cite="http://www.whatwg.org/specs/web-apps/current-work/#alternate0">
The alternate link relationship is transitive
</q>
If you use rel="alternate" for feed autodiscovery as deployed today
(i.e. even when the feed is not an alternate of the page),
transitivity is not assured. This is a clear violation of the
semantics of rel="alternate", so why continue to actively support such
uses?
There's a difference between "deployed uses will continue to work but
you should switch to something better" backwards compatibility and
"the spec will still allow such uses, you can continue to do it that
way" backwards compatility.

Still about feed autodiscovery:
<q cite="http://www.whatwg.org/specs/web-apps/current-work/#feed0">
The first link, a, or area element in the document (in tree order)
that creates a hyperlink with the link type feed must be treated as
the default syndication feed for the purposes of feed autodiscovery.
</q>
I think autodiscovery should be limited to <link> elements in the
<head> of the page (it might already have been discussed –I suppose it
has, it seems to obvious to me–, forigive me in that case)


I hope I clarified my opinion.

-- 
Thomas Broyer