Re: Options for dealing with IDs

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