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

On 16.04.2010 19:28, Tab Atkins Jr. wrote:
> On Fri, Apr 16, 2010 at 10:08 AM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> This does not address the other problem mentioned in ISSUE-86 (about the
>> requirement to create an "undereferenceable" id). Was that intentional?
>
> Yes.  I don't believe it's a problem, and don't think it needs a change.
>
> Do you think it appropriate to address that point?  I suppose this
> does qualify as a counter-proposal.  Then, here you go:
>
> The url produced by the "Otherwise" clause should remain
> undereferenceable.  Without a clear algorithm defining exactly how to
> produce a dereferenceable url, different feed consumers may vary on
> whether a given article's generated URL is dereferenceable or not.  It
> is easy to imagine further tools coming to depend on such an id being
> dereferenceable, and not reacting appropriately when paired with a
> tool that cannot produce dereferenceable URLs for such articles.  This
> will cause interop problems.  I believe that there currently is no
> such appropriate algorithm for defining such a dereferenceable URL,
> and so it is best to simply say that the URL must be
> undereferenceable.  My change proposal already recommends that authors
> ensure that an ID can be generated from one of the previous clauses,
> which do produce a dereferenceable url via a simple and deterministic
> process.

There's not even a defintion of "undereferenceable". Any URI can be 
dereferenced; you just need to define a way to do so.

Can we please stop making up terms and requirements that are totally 
useless, and not required by Atom?

> ...

Best regards, Julian

Received on Friday, 16 April 2010 17:45:06 UTC