- From: Chris Lilley <chris@w3.org>
- Date: Tue, 7 Jan 2003 18:25:14 +0100
- 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" Yes. 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 xml:idAttr="ID" 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