W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

Re: [Minutes] 6 Jan 2003 TAG teleconf (httpRange-14, XInclude conneg, XML next version, namespaceDocument-8)

From: Chris Lilley <chris@w3.org>
Date: Tue, 7 Jan 2003 18:25:14 +0100
Message-ID: <15458299281.20030107182514@w3.org>
To: www-tag@w3.org, "Ian B. Jacobs" <ij@w3.org>

On Tuesday, January 7, 2003, 4:33:22 AM, Ian wrote:

IBJ> [Ian]
IBJ>         TB: It's too late for xml:id. Every language
IBJ>         out there uses "id" to be of type ID.: You
IBJ>         could adopt James Clark's solution, or you
IBJ>         could bite the bullet and say that #id means
IBJ>         the element with the attribute "id"."
IBJ>         CL: Another way (also proposed by James) is to
IBJ>         say that xml:id is decoration.

Just to be clear, that was 'declaration' not 'decoration'. As TimBL
understood when he continued:

IBJ>         TBL: Is this an implicit declaration in all
IBJ>         documents?

To answer the question - xml:id is an implicit declattation (because
its in the xml namespace); xml:idAttr is a declaration mechanism.

IBJ> [TBray]
IBJ>         that's xml:idAttr and you say xml:idAttr="id"


IBJ> [DaveO]
IBJ>         I'd like to make a "matrix" suggestion. What
IBJ>         are the solutions that we are talking about,
IBJ>         and what are there pros/cons?

IBJ> [DanC]
IBJ>         Bray referred to the decoration idea as
IBJ>         "Clark's idattribute" I believe

IBJ> [Ian]
IBJ>         CL: Two ways to do this - declare in namespace,
IBJ>         or do by decoration.:

declaration, again

IBJ> I note that content will
IBJ>         have to be changed anyway.
IBJ>         TB: All this aside, I think that NW's
IBJ>         formulation is correct. We've muddled along and
IBJ>         it doesn't cause practical problems.

Muddling along seems a really porr argument. We have muddled along
without a written web architecture, as well. people muddled along with
SGML before there was XML (ducks) and so forth...

IBJ>         [CL: It does.]

IBJ> [Chris]
IBJ>         Grrrrrrr

IBJ> [Ian]
IBJ>         TB: The risk of slippery slope for just one new
IBJ>         feature is horrendous.

IBJ> [Chris]
IBJ>         It causes *immense* practical problems
IBJ>         GetElementByID is the single most used DOM call

And pointing by id is the most common reference method and the most
stable in the face of document editing.

And styling by id is a greatly preferable methof for one-off overrides
than, for example, the semantically equivalent (in CSS2) but
syntactically inferior style attribute.

So, as long as we are prepared to throw away styling, scripting and
linking well hey, we can generate inanimate pictures of XML documents
just fine ....


IBJ> [Ian]
IBJ>         DO: I would love it if CL listed the various
IBJ>         options for dealing with ids.: I'd like to keep
IBJ>         the issue open to hear the pros and cons.


IBJ>         TBL: In an RDF document, there's not a defining
IBJ>         instance of an id. When something occurs in
IBJ>         more than one place, it's considered to be the
IBJ>         same thing.

RDF/XML, because of its unusual approach to syntax does not have and
will not have a DTD or a W3C XML Schema. These mechanisms are not
suitable for validating RDF; it needs to be validated with something
that understands RDF.

Because of the conflation of validation and decoration (and I do mean
decoration, in this instance) RDF/XML is unable to say that its
attribute called ID is of type ID because the existing mechanisms do
not adequately distinguish decoration (of types, such as ID or anyURI,
and of attribute default values) from validation of the entire
document including its exhaustive content model etc.

xml:idAttr would howerver, very simply and with minimal impact, alow
any RDF/XML instance to simply add


as an attribute to its root element and there you are, none, no DTD
needed or wanted, done and dusted.

 Chris                            mailto:chris@w3.org
Received on Tuesday, 7 January 2003 12:25:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:36 UTC