- From: Tim Bray <tbray@textuality.com>
- Date: Thu, 09 Jan 2003 09:57:35 -0800
- To: Chris Lilley <chris@w3.org>
- Cc: www-tag@w3.org
Chris Lilley wrote: > Hello www-tag, I must say Chris has been eating his wheaties recently, providing much of the input to TAG thinking. > As requested by Dave Orchard, a listing of the options for dealing > with IDs. > > 1) Require DTD validation of all instances. Not a serious option IMHO. > 2) Steal all attributes of name id in the per-element partition > Declare retrospectively that all attributes whose name is 'id' are of > type ID because this is common practice anyway. I think if we did this there would be howls of protest which would die away within a few weeks and the world would be a better place. > 3) Steal undeclared attributes of name id > In well formed content that does not have a DTD, or that has a > partial DTD used for decoration (declaring ID, declaring attribute > defaults, etc) if an attribute is called id and has not been > declared in the DTD, it is of type ID. Isn't this a variation of #1? I.e. it requires that interoperable processing requires fetching and looking in a DTD. So probably not realistic. > 4) Add a predeclared id attribute to the xml namespace This would cause slightly more impact on deployed software/data than #2, but would still leave us ahead in the medium/long term, I could live with it. > 5) Add an inline, per-instance ID declaration method > 6) Add an inline, per subtree ID declaration method I prefer #5 to #6 on grounds of simplicity, but at this point in time I do not believe XML needs to adopt yet another type-declaration mechanism. This is a slippery slope, camel's nose, pick your metaphor... once we've got this we need to declare IDREF and then why don't we add something saying whether order of children is significant, and which attributes are URIs, etc etc etc. I don't think we have enough experience in hand to start down this road. > 7) Muddle along > Do nothing. Accept weasel wording in the DOM spec about knowledge of > 'well known namespaces' and conformance loopholes in the CSS spec > about possible breakage in namespaces other than HTML and accept > that we can't really point into XML documents unless we can be sure > the client uses a validating parser and besides, it works in HTML so > far and no-one really uses XML on the client anyway. I'm fine with this. You can safely point into any XML document that has a proper media-type registration in place, so you really only have problems with resources served as */xml, which is something that in general Should Not Be Done, and fortunately generally isn't done. Really, forget about following pointers, do you really think it's good practice to write and publish a foo#bar URI ref into something of which you don't know the media-type? I don't. And if you know the media-type there's no problem. So I counsel inaction. BTW, if the DOM is using weasel words they should just $@#!% well clean them up and say that the notion of ID-ness is entirely DTD-dependent, which it is. It's perfectly OK for a DOM implementation to know what the ID attributes are based on the namespace or media type without having to read the DTD, so what's the problem? Once again, it only arises when you only know it's XML and you don't have a DTD, and I think we just have to live with not knowing the ID in that scenario. > 8) Require W3C XML Schema validation of all instances. See #1. > My personal preference is for option 6) Add an inline, per subtree ID > declaration method. It would require work on what the precedence is > (or what sort of error it is) if the DTD or Schema declares the > designated attribute to be of a type other than ID. It would require a *lot* of work, with high chances for error and unintended consequences & side-effects. I'd say let's just not go there. -Tim
Received on Thursday, 9 January 2003 12:57:43 UTC