On Tuesday, July 12, 2005, at 06:21 PM, A. Pagaltzis wrote:
* Thomas Broyer <[EMAIL PROTECTED]> [2005-07-13 00:00]:
As an atom:id is an identifier that might (should?) not be
"dereferenceable", atom:link is not a good choice.
There is nothing in the spec that forbids atom:link
That should be "atom:id", right?
from being
dereferencable, nor anything that advises against it being so.
See 4.2.6 and 4.2.6.1 in -09.
...
The spec just says is that the URI MUST NOT be assumed to be
dereferencable,
...
Whether atom:link is a bad choice for carrying a non-
dereferencable URI around is a better argument. The spec says,
verbatim:
The "atom:link" element defines a reference from an entry or
feed to a Web resource.
That would seem to imply dereferencability, but is open to
interpretation.
...
Personally, I would prefer to interpret the spec liberally, if
that is within the intended spirit,
It's definitely not within the spirit that I, for one, intended. But
the spirit that I intended (atom:link being limited to links intended
to be traversed in response to explicit user interaction) was not
accepted by the WG, so perhaps that has little bearing.
If atom:link is intended to be dereferencable, then clearly, any
solution that takes a value from atom:id and puts it into
atom:link/@href has a strike against it since any feed that uses
non-dereferencable atom:ids would either have to violate the spirit of
atom:link to participate in the feature, or would have to invent a
competing solution.
Also, if a feed that uses dereferencable atom:ids is relocated, clients
would be much more likely to attempt to dereference the atom:links that
carried those previously dereferencable values than an extension
element that was explicitly defined as not necessarily dereferencable.
