W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2006

[whatwg] PaceEntryMediatype

From: Thomas Broyer <t.broyer@gmail.com>
Date: Sun, 3 Dec 2006 15:26:45 +0100
Message-ID: <a9699fd20612030626o49271518pc3281c738495bb87@mail.gmail.com>
2006/12/2, Ian Hickson:
> On Sat, 2 Dec 2006, Thomas Broyer wrote:
> >
> > 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.
>
> Oh. If you just mean that you don't think there should be a way to say
> that a particular document is a syndication feed, then I disagree. I would
> assert that the popularity of feed readers such as Bloglines, Google
> Reader, and so forth, is evidence that many other people find this feature
> useful as well.

It all depends on the definition of "syndication feed".

What I mean is that "being syndication feed" is not a property of a
relationship, it's a property of one end of the relationship (the
resource the link "starts from" or "points to"); so it has nothing to
do with the rel="" attribute.

> > 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").
>
> So you're proposing making the hundreds of millions of existing instances
> of syndication feed links non-conforming?

No more than they already are.
rel="alternate" is for linking to alternate representations, and
hundreds of millions of syndication feed links are not using it that
way; they already are non-conforming.

And note that this is something that is not machine-testable, that's
why those hundreds of millions of syndication feed links are not
caught as "invalid" by validators, as they won't be whatever HTML5
finally says.

> > I hope I clarified my opinion.
>
> Actually I'm even more confused now than before. Could you propose exact
> normative replacement text for the specification that would make you
> happy? In doing so, please consider these constraints:
>
>  * We cannot define anything to do with the user interface, only the
>    meaning of the link relationships, because user agents must be allowed
>    to innovate in user interfaces (basically, only interoperability can
>    be ensured, not homogeneity).
>
>  * We don't want to break existing practices. If something is
>    interoperably implemented and widely used, then it should continue to
>    work in the same way.
>
>  * The specification should be kept as simple as possible.

In 4.4.3.1 (Link type "alternate"), remove this paragraph:
"""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."""

Remove rel="feed" or, if you really think it's different from
rel="index", define it that way:
"""The feed keyword indicates that the referenced document is a
syndication feed which is or has been linking to the current page as a
feed item.
For example, in a Web log, a page representing a single entry can link
to the Web log homepage and/or the Web log's Atom or RSS feed using
using the link type feed."""

Anyway, in 4.4.3.7 (Link type "feed"), remove this paragraph:
"""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."""
Also remove the examples from this same section.

If you really want to deal with feed autodiscovery (which I believe it
shouldn't be part of HTML5), add something like this to section 3.5.4
(The link element; feed autodiscovery should be limited to <link>
elements, and given that it's how it's done today, it causes no
backwards compatibility problem):
"""For example, external resource links with the type attribute set to
the value application/rss+xml or the value application/atom+xml or
with the link type feed may be recognized as links to subscribable
resources for the purpose of feed autodiscovery.
"""
This could be added, for example, just after this paragraph:
"""For external resource links, user agents may use the type given in
this attribute to decide whether or not to consider using the resource
at all. If the UA does not support the given MIME type for the given
link relationship, then the UA may opt not to download and apply the
resource."""
And it could be accompagnied by examples:
<div class="examples">
<p>The following link:</p>
<pre>&lt;link rel="alternate" type="application/atom+xml" href="A"&gt;</pre>
<p>?indicates an alternate representation of the current document as
an Atom Document, which might be subscribed to.</p>
<p>If a document contains two links labeled as follows:</p>
<pre>
&lt;link rel="feed" type="text/html" href="A"&gt;
&lt;link rel="feed" type="application/atom+xml" href="B"&gt;
</pre>
<p>?then it means the current document appears or has been appearing
as a feed item in the linked external resources, one in HTML format
(for example a Web log's homepage) and the other as an Atom Document
(for example the Web log's feed)</p>
</div>

-- 
Thomas Broyer
Received on Sunday, 3 December 2006 06:26:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:31 UTC