W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: change proposal for issue-86, was: ISSUE-86 - atom-id-stability - Chairs Solicit Proposals

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 15 Apr 2010 21:43:08 +0200
Message-ID: <4BC76C4C.8000607@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: Edward O'Connor <hober0@gmail.com>, Sam Ruby <rubys@intertwingly.net>, "public-html@w3.org WG" <public-html@w3.org>
On 15.04.2010 21:30, Ian Hickson wrote:
> ...
> Wouldn't this just mean that the algorithm would fail to generate anything
> at all in most cases? (I'm assuming most<article>s don't have an ID or a
> rel=bookmark.) That seems like a problem, if the goal is to get each
> article into a feed.
> ...

If that's the goal, no matter what the input is, than I don't think it's 
achievable.

> To put it another way: the goal here is that if someone wants to get their
> HTML file turned into a feed, they have a set of steps they can follow
> that reliably give a predictable result, so that they can use off-the-
> shelf software to do it and can later change to different software and get
> the same result.

That could also be achieved by clearly stating the requirements on the 
HTML source, and by requiring the conversion not to generate broken 
output (but to abort on either the feed or entry level instead).

> If we make that algorithm not work for many cases, then people are going
> to extend the algorithm in proprietary ways (all of which still violate
> Atom), and then moving from one piece of software to another is going to
> be expensive.

If these extensions do not produce properly working Atom output, then I 
don't see a problem. If they do, then, maybe, these extensions do 
something that the algorithm could have specified in the first place.

> To put it a third way: if our goal is to wash our hands of the
> responsibility of people violating the Atom spec in cases where the Atom
> spec's requirements are fundamentally impossible to achieve while still
> generating an Atom feed, we can do that easily. But doing so also means
> washing our hands of the responsibility to give authors and users an
> interoperable mechanism that actually works.

Why are we, the HTML WG, responsible for that? Who decided that? And, 
even if we were, what does this exactly mean if it's impossible to achieve?

Best regards, Julian
Received on Thursday, 15 April 2010 19:44:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:16 UTC