I *really* don't want to get into a protracted debate that gets us going
back and forth between atom:[EMAIL PROTECTED]"in-reply-to"] and thr:in-reply-to
when either approach would work just as well as the other. The
thr:in-reply-to tends to make the most sense to me at this point because
of the need to a) do ID refs and b) identify the source of a link as a
part of the link itself ... both of which *could* be done with atom:link
but only with a bit of massaging and a namespace extension (to introduce
idref). Since either solution requires namespace extensions to be
added, thr:in-reply-to is likely the better option (IMHO).
What I will say is that it is rather unfortunate that Link wasn't
conceptualized the way the Author, Date and Text constructs were. If
there had been a Link construct in the spec that defined a common base
for Link oriented elements, it would have made it very simple for me to
do something akin to the following:
atomLink {
atomCommonAttributes,
attribute href {URI}?,
attribute idref {URI}?,
attribute title {text}?,
attribute hreflang {text}?,
}
inReplyTo = element thr:in-reply-to { atomLink }
Ah well...
- James
Eric Scheid wrote:
On 11/8/05 3:20 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
As long as producers throw in atom:[EMAIL PROTECTED]'related'] pointers
to the source as well, that base is covered anyway.
I'd prefer to see atom:[EMAIL PROTECTED]"in-reply-to"].
Of course it's "related". All links in an entry point to related resources,
that's the very definition of a link. We also know what the nature of the
relationship is (it's in reply to that resource), so it doesn't hurt to
specify that.
James -- any chance of defining that in the comments draft, alongside the
'replies' link relation. You could then simplify the thr:in-reply-to element
to just needing to handle the thr:idref case.
e.
