[whatwg] PaceEntryMediatype

[Ian Hickson]

On Sun, 3 Dec 2006, Thomas Broyer wrote:
> >
> > 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.

I agree, in principle. Unfortunately, for autodiscovery we have to have a 
mechanism that can advertise what the syndaication feeds are without 
requiring the UA to fetch every link, because fetching every link would 
be much slower (and on some networks, fiscally more expensive).


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

Fair enough. They still exist, though. Browser vendors aren't going to 
stop supporting this. We would be just sticking our heads in the sand if 
we ignored this.


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

When people link to an Atom document, they are giving a syndication feed. 
I'm sure theoretically there could be other uses of Atom, but from my 
studies of Web content, I haven't seen any evidence that this is 
widespread enough to deserve special treatment.


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

Removing this paragraph breaks existing practices.


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

There are syndication feeds that don't fit this definition. For example, a 
home page could link to various feeds for things like planned outages, 
news, press releases, etc, not all of which might be on the page itself.


> 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 is not well-defined enough. We need something far more specific than 
an example in order to foster interoperability. Also, I don't really see 
how the end result here is anything different from what the spec says, 
other than being more vague.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'