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: Ian Hickson <ian@hixie.ch>
Date: Thu, 15 Apr 2010 19:30:47 +0000 (UTC)
To: Edward O'Connor <hober0@gmail.com>
Cc: Sam Ruby <rubys@intertwingly.net>, Julian Reschke <julian.reschke@gmx.de>, "public-html@w3.org WG" <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.1004151914180.23507@ps20323.dreamhostps.com>
On Thu, 15 Apr 2010, Edward O'Connor wrote:
> Sam wrote:
> >>> One possible way to address this is for section 5.5.3, step 15,
> >>> substep 9, otherwise clause be modified to throw an
> >>> INVALID_STATE_ERR exception if it is not possible to generate an
> >>> entry id in a way that ensures uniqueness.
> I replied:
> >> Suppose there's an HTML document with several<article>s, only one of
> >> which triggers the "otherwise" clause of step 15, substep 9. Instead
> >> of throwing an exception and aborting--not producing any feed at
> >> all--why not just leave out that one problematic<atom:entry> from the
> >> resulting feed? So instead of "or ... you don't produce an Atom
> >> feed," we don't produce an Atom *entry* for that specific<article>.
> Sam replied:
> > Sounds plausible. This, however, suggests that algorithm isn't fully
> > "baked" yet[...]
> I wouldn't read that much into it. This algorithm, like everything else
> in the spec, has room for improvement. I think my suggestion above might
> be such an improvement. Let's wait to see if Ian agrees to change the
> algorithm as I've suggested. If he does, ISSUE-86 would become a
> non-issue.

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.

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.

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.

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.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 15 April 2010 19:31:15 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:01 UTC