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

On 04/15/2010 04:49 AM, Ian Hickson wrote:
> On Thu, 15 Apr 2010, Julian Reschke wrote:
>> On 15.04.2010 01:08, Ian Hickson wrote:
>>> ...
>>>>> Basically making this a MUST would lead to implementations having
>>>>> to violate the spec to do anything useful. When we require that
>>>>> implementations violate the spec, we lead to them ignoring the
>>>>> spec even when it's not necessary.
>>>>
>>>> Based on my experience with feeds (predating Atom), this part of the
>>>> spec will not be ignored.  Users will write bug reports against the
>>>> software that implements the algorithm.
>>>
>>> If a feed producer has to invent an ID from nothing, and doesn't know
>>> what ID it used in the past, yet the spec uses "MUST" here, how
>>> exactly can it do anything _but_ ignore the spec?
>>
>> Either you store the ID with the item, or you derive the ID from
>> something sufficiently unique in the set of items, or ... you don't
>> produce an Atom feed.
>
> Storing an ID doesn't work when you're on a read-only medium.
>
> A hashing mechanism by which we can generate an ID from a DOM tree would
> end up making identical posts in unrelated Atom feeds have the same ID,
> and would mean that minor edits (e.g. typo fixes) would generate new IDs,
> both of which would cause all kinds of problems, as Sam pointed out.
>
> Not producing a feed doesn't solve the problem of producing a feed.
>
> Therefore if we make this a MUST in the HTML spec, we are just adding a
> requirement that will in some cases be ignored. This is functionally
> equivalent to a SHOULD, which is what the spec has now.
>
> If you prefer a process-based argument: we can't progress past CR if we
> can't find two interoperable implementations of every feature. If one of
> the features is "you must make consistent IDs for HTML<article>s when
> converting them to Atom, even if they are slightly modified from time to
> time, and even if you have no persistent storage, and you must not create
> IDs that conflict with other entries", then we won't be able to exit CR,
> because that requirement is not implementable.
>
>> What the Atom spec is the result of VERY long discussions, and when it
>> says MUST then it's because the Working Group really wanted it that way.
>
> And nothing we do here can change what the Atom spec says. I don't see the
> problem. We're not making it ok to create invalid feeds. We're just saying
> that if you can't create a valid feed, that's an Atom conformance error
> and not an HTML conformance error.

I think that there is a hidden assumption in there some place, but I'm 
not sure.  Perhaps something along the lines of "all conforming HTML 
pages should be able to produce something resembling an Atom feed using 
the algorithm specified in section 5.5.3", and that it is harmless to do 
so even if the feed produced technically violates the letter of the Atom 
specification, but as I said, I'm not sure.

I do believe that the following are all true:

1) it is the case that some HTML pages can be processed in such a
    way as to produce a useful Atom feed.
2) some people find ability this desirable
3) entry ids that are not created in a way that ensures uniqueness
    not only is technically violated the spec, but are generally
    problematic
4) many who implement the algorithm currently in the spec have no
    interest or ability to manage state

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.

A consequence of this is that there will exist conforming documents for 
which this exception will be thrown if this algorithm is implemented. 
Perhaps some validators can be produced which have an option to check 
for such conditions.

- Sam Ruby

Received on Thursday, 15 April 2010 13:00:49 UTC