Re: 4. ID assignment and the empty string

Chris Lilley <chris@w3.org> writes:

> IH> This change does satisfy my concern, thanks!
>
> Leaving something deliberately unspecified is one way to proceed, but
> not a way that I like.

It never was (intended to be) specified at this level in this spec.

>
>>>   Application-level processing of IDs, including which elements can
>>>   actually be addressed by which ID values, is beyond the scope of
>>>   this specification.
>
> IH> Just out of interest, which specification _does_ have this in scope?

Lots -- see below.

> That was my concern on seeing this resolution. While it makes the xml:id
> spec more self contained, it also increases the risk of lack of clarity
> or a logical disconnect for specifications that might make use of xml:id
> (or makes it more likely that such specifications need to be revised to
> make use of xml:id).
>
> Falling between two stools is a problem; this resolution seems to
> increase the gap between stools.

I think it just accurately reflects the situation.  Different RECs
contain _different_ definitions of the point at issue.  I count at
_least_ five:

 * XML 1.0 and 1.1 say an IDREF is *valid* iff there is a _single_
   ID somewhere which is a Name.

 * XML Namespaces says it has to be an NCName.

 * XPath 1.0 says the first ID-typed value (note not required to be an
   Name _or_ unique) discharges an id(...).

 * XPointer says the first NCName (no uniqueness requirement) is
   what's pointed to by a shortform identifier.

 * XML Infoset 2e says it has to be unique to be [reference]d, but is
   somewhat unclear about whether it has to be an Name or an NCName.

And I'm sure there are others, at least the DOM, which I don't know
off the top of my head.

Under the circumstances we made a conscious decision _not_ to go all
the way to saying what role attributes of type ID played downstream,
because to do so would have been to pre-empt downstream apps/specs
from making the kind of different choices exemplified above.

What this means going forward is that over time downstream specs will
need to add support for xml:id -- we don't see how else things could
be managed.  Note that in fact we're actually in pretty good shape in
this regard, because XPointer anticipated xml:id so when RFC3023 is
revised to bless XPointer (hint hint) xml:id attributes will
immediately become legitimate targets for fragment ids for URIs
pointing to resources with .../xml... media type, and the forthcoming
XPath 2.0 WD also has xml:id support built in.

ht
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

Received on Thursday, 3 February 2005 09:54:11 UTC