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 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. This would mean inReplyToNonDereferenceable is mainly reserved for replies to Atom Entries, and replies to other types of entities are relegated to inReplyToDereferenceable. I believe it is sensible to legislate this segregation further by saying that inReplyToDereferenceable SHOULD NOT be used to reply to entities which have an Atom Entry representation. PS.: a minor editorial niggle: > [2. Notational Conventions] > > In this specification, "head section" refers to the children > of a feed's document-wide metadata container; e.g., the > child elements of the atom:feed element in an Atom Feed > Document. I believe this sentence should end with “other than atom:entry” to remove any ambiguity. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
