[Bug 4519] [XDM] Definition of is-id property

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4519





------- Comment #5 from cmsmcq@w3.org  2007-08-02 18:10 -------
In a recent call, I expressed some reservations about the interpretation of 
XSDL 1.0 reflected in comment #3.  It's correct that XSDL 1.0 Structures
treats values as IDs (by enforcing the relevant uniquness constraint) if
and only if their type is ID "or derived from ID".   And it's true that
in XSDL 1.1, the term "derived from" is used of simple types only to cover
restriction, not the list or union constructions.  But in XSDL 1.0 Structures,
the term "derived" is not formally defined as a term, and in 1.0 Datatypes
it is used both for derivation by restriction and for construction by list
and union.  (IDREFS, for example, is described as being "derived from" IDREF.)

So in principle, at least, it's possible to argue that 1.0 Structures should
be read as attributing ID-hood, IDREF-hood, and IDREFS-hood, respectively,
to lists whose item types are ID, IDREF, or IDREFS, and also to unions which
have ID, IDREF, or IDREFS as member types.

The rules for constructing the ID/IDREF table, however, lead to unexpected
and implausible results if given this interpretation.  If type T1, defined 
as list of ID, is treated as having ID-ness, then if the list "a b c" is
encountered in the document with type T1, the ID/IDREF table gets an entry
for the list "a b c", NOT for the individual items a, b, and c.  And if
type T2 is a union of int and ID, then any value of the union would get an
entry in the table, not just the IDs.  These consequences persuade me
that in the relevant passages "derived from" means only derived by 
simple type restriction or derived by extending a simple type to form a
complex type with simple content.

So the skepticism I expressed on the call appears to have been misplaced;
the interpretation of XSDL 1.0 offered in comment #3 seems the only
plausible one.

Received on Thursday, 2 August 2007 18:10:56 UTC