On Thu, 13 Oct 2005, A. Pagaltzis wrote:
Hi James,
* James M Snell <[EMAIL PROTECTED]> [2005-09-08 06:45]:
If anyone has any further comments on the draft, please let me
know.
I am alarmed that this draft does *not even once* explicitly
mention the fact that idrefs are expected to be derived from Atom
Entry IDs. No particular interpretation of @idrefÿÿs content is
prescribed at all.
I believe that's because they're not necessarily expected to be derived
from Atom Entry IDs. The idref is dependant on the type of content being
referenced. For an application/atom+xml content type, the reference would
be a Atom Entry ID. Other source documents than Atom may be used as thread
references - otherwise the threading system would be limited to only
allowing Atom people to respond to Atom people.
I think this is a terrible mistake.
If consumers cannot have a uniform expectation of the meaning of
the @idref value, there is no way for an Atom producer to know
how to express a particular notion. I am uncomfortably reminded
of RSS. If we do want consumers to have a uniform expectation of
the meaning of such a value, then people who decide to stick
something else in there will fail to interoperate with the
majority of consumers.
In other words, this is an obvious case for a SHOULD-level
requirement.
So, I believe the draft as it stands is seriously lacking because
it misses one crucial sentence in the section 3 paragraph that
deals with inReplyToNonDereferenceable.
As to *what* the SHOULD-level requirement should be, I think
there will be little argument that the ID of an Atom Entry is it.
If any additional wording is necessary, then it should be explicit that it
only relates to the media type of 'application/atom+xml'. It is, in my
opinion, redundant to say this because ID reference for a
application/atom+xml document is the Atom Entry ID. Other media types
would use their own forms of identifiers.
[snip]
--
Gerph <http://gerph.org/>
... I can see it, but it's only real when they hide me from the truth.
