2006/3/16, Sylvain Hellegouarch <[EMAIL PROTECTED]>:
> > It could lead to confusion, but as Atom doesn't define such an
> > attribute in its own namespace (or on elements in its own namespace)
> > and as no other extension that I know of do that either, I don't think
> > it really matters…
>
> You are right Atom does not define such an attribute but I'd be happier
> if extensions could follow Atom conventions as well. Atom sets the
> atom:id value not as in an attribute of atom:id but as its content. Why
> not following the convention in the first place?

Because they don't deserve the same role. atom:id gives the identifier
of the resource _described_ by the containing element, while
thr:in-reply-to/@id gives the identifier of the resource _referenced_
by the containing element (or, actually, gives an identifier _as a
reference_ to this resource). In that sense, thr:in-reply-to deserves
the same role as @href. If you get back to previous versions of the
threading extension, you'll see that it had been proposed that there
would only be @href, whether or not the given IRI were to be
dereferenced (e.g. by making an HTTP request) or just used as a
globally unique identifier. This has been worked out because a) people
(including me) wanted that these roles (retrieving vs. identifying) be
clearly distinguished and b) there wouldn't then have a mean to give
both the resource identifier and an IRI where to retrieve a copy of
it.

> > Having an attribute named "id" doesn't make it an "ID" (in the sense
> > of a unique identifier throughout the document, such as the ID type in
> > a DTD of xs:ID in XMLSchema), […]
>
> Again this is a matter of convention in my opinion. When reading an XML
> document I don't want to be obliged to think about the actual meaning of
> an id attribute. You are indeed right (and thank you for explaining it
> to me) in terms of specification but conventions are often as important.
> Specially for people like me who are not XML guru.

Well, I wouldn't describe myself as an XML guru either ;-)

--
Thomas Broyer

Reply via email to