Re: MPEG-7 Problem Issues and Queries

Michael,

It is my understanding that when checking the value of a simple type against
a 'candidate' union type if that check fails then the value is checked
against the next candidate type. So I would say that (a) is correct.

What this means is that without putting xsi:type into the instance the value
'foo' will never be decorated as having the type mpeg7:xpathType. It will
always be either IDREF ( if the corresponding ID exists ) or uriReference.

However, you may be correct in that the outcome may be related to the
lexical space of IDREF. If the lexical space is all XML names then obviously
'foo' is a valid name. If the lexical space is all XML names that appear in
attributes in the input infoset whose type is ID then 'foo' may or may not
be valid. So this issue may be affected by the resolution of CR-14 ( and
possibly CR-15 aswell ).

Gudge

----- Original Message -----
From: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
To: "Biron,Paul V" <Paul.V.Biron@kp.org>
Cc: "'Jane Hunter'" <jane@dstc.edu.au>; <www-xml-schema-comments@w3.org>;
<mpeg7-ddl@darmstadt.gmd.de>
Sent: Wednesday, January 10, 2001 5:40 AM
Subject: RE: MPEG-7 Problem Issues and Queries


> 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?
>
> -C. M. Sperberg-McQueen
>

Received on Wednesday, 10 January 2001 10:56:33 UTC