W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2001

Re: MPEG-7 Problem Issues and Queries

From: David Beech <David.Beech@oracle.com>
Date: Wed, 10 Jan 2001 15:53:29 -0800
Message-ID: <3A5CF5F9.6DB9F74B@oracle.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:12:49 GMT