- From: David Beech <David.Beech@oracle.com>
- Date: Wed, 10 Jan 2001 15:53:29 -0800
- To: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
- CC: "Biron,Paul V" <Paul.V.Biron@kp.org>, "'Jane Hunter'" <jane@dstc.edu.au>, www-xml-schema-comments@w3.org, mpeg7-ddl@darmstadt.gmd.de
"C. M. Sperberg-McQueen" wrote: > > At 2001-01-02 10:23, Biron,Paul V wrote: > > > ----------------------------------------------- > > > 3. Union and IDREF > > > > > > Each IDREF must match a corresponding ID within the XML instance document > > > in > > > which it occurs. Can we expect that this rule also applies when IDREF is > > > used > > > within a <union>? According to XML Schema definition, it seems not: > > > > > > [Definition:] Union datatypes are those whose *value spaces* and > > > *lexical spaces* are the union of the value spaces and lexical > > > spaces of two or more other datatypes. > > > > >I'm not sure I understand the question, given that and IDREF is an IDREF > >whether it occurs as part of a union or not. Why would an IDREF not have to > >match an ID in the instance document when IDREF is used in a union? > > I'm not sure this is the same question JH and MPEG 7 had in mind > (so I am copying them on this to ask), but the posting does raise the > following question in my mind: > > If we have the union type 'referenceType' defined as shown, i.e. > > <simpleType name="referenceType"> > <union memberTypes="IDREF uriReference mpeg7:xPathType"/> > </simpleType> > > Then let us consider the following cases: > > Case 1: we get the value 'http://www.w3.org/' for an instance of this > type. The schema processor will see whether this is an IDREF value, > and determine on lexical grounds that it cannot be, so it will try > it as a uriReference value, succeed, and decorate the PSVI accordingly. > > Case 2: we get the value 'foo' for an instance of this type. The > value 'foo' matches an ID in the document, and the schema processor > recognizes the value as being of type IDREF. > > Case 3: we get the value 'foo'. The value 'foo' does not match any > ID in the document. What happens? > > (a) the schema processor realizes this isn't an IDREF and tries > it as a uriReference value (where it will succeed regardless > of whether there is a resource identified by 'foo')? or > (b) the schema processor says 'Well, this is a legal IDREF > value (i.e. it is a NAME), but it does not match any ID in > the document, so it is not correct' and raises an error? > > Depending on how we define the value space of IDREF -- itself a > topic of discussion in other CR comments -- a language lawyer might > be tempted to make a case for either of these resolutions. > > Based on section 2.5.1.3 of the spec, however, and the sentence > "During validation, an element or attribute's value is validated > against the memberTypes in the order in which they appear in the > definition until a match is found", I believe the correct answer to > my question is (a). > > I have two questions of my own: > - do other people believe the answer to my question is (a)? > - is this the question Jane Hunter and MPEG 7 were asking? Our implementors adopted the interpretation (b). This seems less brittle than making the resolution of a union vary as ids are added to or removed from a document. Do we in any case have a recorded issue as to whether the value space of IDREF is defined to be document-dependent, or to be the invariant set of values corresponding to the permitted lexical representations? Personally, if that is open for discussion (if it isn't, you didn't read what follows), I favor the invariant value space for a type, which is also consistent with the way that keyrefs work using ordinary types with invariant value spaces. Additional constraints are applied to certain usages of those types, but I don't think we'd say that the _value space_ of e.g. xsd:integer is thereby changed. Thanks, David
Received on Wednesday, 10 January 2001 18:57:06 UTC