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

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.

Further, if an attempt to create such an algorithm were made, I
suspect that a common class of solutions would use some form of
positional selector, similar to the capabilities of XPath or
Selectors, which would generate a different url (and thus entry ID) if
the page producing the feed was rearranged, but the article itself was
unchanged.  This would violate the MUST requirement in the "Otherwise"
clause for generating the same id given the same input, and would
cause undesirable user experiences for the users of feed consumers.

~TJ

Received on Friday, 16 April 2010 17:28:53 UTC