Subject: Re: Atom Comments Extension

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 13 Oct 2005 22:23:26 +0200

Hi James,

* James M Snell <[email-masked]> [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/>

---

From: Justin Fletcher <[email-masked]>
Date: Fri, 14 Oct 2005 21:51:03 +0100 (BST)

On Thu, 13 Oct 2005, A. Pagaltzis wrote:

> 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.

> 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.

---

From: "Roger B." <[email-masked]>
Date: Mon, 17 Oct 2005 19:19:05 -0500

> from Atom Entry IDs.

Agreed. I've been making experimental use of the extension with RSS,
and will continue to do so... no Atom IDs in sight.

 --
Roger Benningfield

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 18 Oct 2005 04:28:50 +0200

* Justin Fletcher <[email-masked]> [2005-10-14 23:00]:
> 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.

Well yes, you’re right. But I’d really want to see at least
*some* explicit mention of using Atom IDs as idrefs somewhere in
the spec. However redundant it may seem, I’d feel more
comfortable if it wasn’t merely implied.

F.ex., say you’re replying to one of Tim’s ongoing entries. This
means @idref will be a HTTP URI. If someone views source and
concludes he should put the permalink in there, what would you
tell them? It works with Tim’s feed and there’s nothing in the
spec which says what they’re doing is wrong either. But if
consumers expect entry IDs in there, it will fail if they start
replying to feeds using some other form of URI for their IDs.

This clearly is an interoperability issue.

In fact, now that I think about it, it seems that recognising
that this extension should be applicable beyond Atom doesn’t mean
it should be less explicit about what to use for identifiers, but
rather should be more so: it should explicitly mention what
should be used as an identifiert when replying to items from RSS
feeds as well. (Eg. use the GUID as an idref when available,
otherwise use the permalink as a href.)

Regards,

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Oct 2005 20:26:23 -0700

>comfortable if it wasn’t merely implied.
+1.  I'll make that change

>This clearly is an interoperability issue.
+1

- James