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

On 04/15/2010 03:30 PM, Ian Hickson wrote:
> 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.

Forgive me, outside of perhaps Edward O'Connor (and actually I strongly 
suspect that he will agree with the following statement), I don't expect 
that the use case is "I want to produce something that may or may not be 
valid and may or may not be useful, just so long as it vaguely resembles 
an Atom feed".  If anything, I think the use case is "I want to produce 
something that people can use in NetNewsWire (whether that is RSS 1.0 or 
Atom or CSV files, I care not)."

I'll be honest here: if we were talking about feed IDs, I would be hard 
pressed to demonstrate the practical effects of what happens if they 
were invalid or outright omitted.  But we are talking about entry ids 
(and I will submit: entry dates).  There are very real consequences, and 
observable consequences to putting in data that changes each time that 
data is extracted.

I've suggested three times now that you actually try it.  I'll even make 
it easy for you: here are two feeds:

   http://intertwingly.net/stories/2010/04/15/example.stable
   http://intertwingly.net/stories/2010/04/15/example.unstable

The only difference between these feeds are that the ids and updated 
dates change every second in the unstable version.  Try it in as many 
feed aggregators as you like.  Be aware that many only poll once an 
hour, so check back a few hours later and see what is displayed.

- Sam Ruby

Received on Thursday, 15 April 2010 19:47:50 UTC