Re: (Re)^2: Question on id constraints

[Eddie Robertsson <eddie@allette.com.au>]

Hi Christian,

> Firstly, there is no restriction where to specify the keyref.

The spec is very confusing with regards to these issues and I'm not sure if the
spec actually restricts the placememnt of the keyref declaration or if it just
specifies how it should be declared to work properly. There was a discussion
about this a couple of weeks ago on xmlschema-dev that clarified theses issues.

See http://lists.w3.org/Archives/Public/xmlschema-dev/2001Jul/0010.html

> But if the keyref is specified in a descendant it is quite useless.

Yes.

> The example from the specification does so:
>
> <xs:element name="state">
>  <xs:complexType>
>   <xs:sequence>
>    <xs:element name="code" type="twoLetterCode"/>
>    <xs:element ref="vehicle" maxOccurs="unbounded"/>
>    <xs:element ref="person" maxOccurs="unbounded"/>
>   </xs:sequence>
>  </xs:complexType>
> ...
>  <xs:keyref name="vehicleState" refer="state">
>   <!-- every vehicle refers to its state -->
>   <xs:selector xpath=".//vehicle"/>
>   <xs:field xpath="@state"/>
>  </xs:keyref>
>
> </xs:element>

<snip/>
Where did you find this example?
I tried to find this in the spec but the only one I could find (which is very
similar) is the one in [1]
which looks like this:

              ......
             <xs:element name="vehicle">
              <xs:complexType>
               . . .
               <xs:attribute name="plateNumber" type="xs:integer"/>
               <xs:attribute name="state" type="twoLetterCode"/>
              </xs:complexType>
             </xs:element>

             <xs:element name="state">
              <xs:complexType>
               <xs:sequence>
                <xs:element name="code" type="twoLetterCode"/>
                <xs:element ref="vehicle" maxOccurs="unbounded"/>
                <xs:element ref="person" maxOccurs="unbounded"/>
               </xs:sequence>
              </xs:complexType>

              <xs:key name="reg"> <!-- vehicles are keyed by their plate within
states -->
               <xs:selector xpath=".//vehicle"/>
               <xs:field xpath="@plateNumber"/>
              </xs:key>
             </xs:element>

             <xs:element name="root">
              <xs:complexType>
               <xs:sequence>
                . . .
                <xs:element ref="state" maxOccurs="unbounded"/>
                . . .
               </xs:sequence>
              </xs:complexType>

              <xs:key name="state"> <!-- states are keyed by their code -->
               <xs:selector xpath=".//state"/>
               <xs:field xpath="code"/>
              </xs:key>

              <xs:keyref name="vehicleState" refer="state">
               <!-- every vehicle refers to its state -->
               <xs:selector xpath=".//vehicle"/>
               <xs:field xpath="@state"/>
              </xs:keyref>

              <xs:key name="regKey"> <!-- vehicles are keyed by a pair of state
and plate -->
               <xs:selector xpath=".//vehicle"/>
               <xs:field xpath="@state"/>
               <xs:field xpath="@plateNumber"/>
              </xs:key>

              <xs:keyref name="carRef" refer="regKey"> <!-- people's cars are a
reference -->
               <xs:selector xpath=".//car"/>
               <xs:field xpath="@regState"/>
               <xs:field xpath="@regPlate"/>
              </xs:keyref>

             </xs:element>

Here all the keyref's are specified on the root element and the schema looks
fine to me.

Cheers,
/Eddie

[1] http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#declare-key


> This example is wrong in that sense, that it has NOT the semantics verbally
> given in the specification:
> This is why:
>
> The vehicleState-keyref will be examined if currently validating a
> state-element.
> The state element declaration contains neither directly nor indirectly the
> root element declaration, so state-element instances won't contain
> root-element instances.
> The identity contraint table to use is that of the state-element currently
> validated.
> This table will never contain entries for the state-KEY, because the
> state-KEY is defined in the root-element declaration and as mentioned above,
> state-elements never contain root-elements and whats in the table and what
> not follows from section 3.11.5.
> So each vehicle-Element bearing a @state-attribute (AFTER normalization) can
> NOT be validated, because having a @state-attribute implies beeing in the
> qualified node set (in this example).
>
> So your right in your statement, that keyref can not be defined in an
> ancestor, because this is semantically useless, although syntactically
> allowed.
>
> But this can not be the intention, so the problem remains: What is the
> intentional semantics of keyref because the example above should have the
> verbally given meaning?
>
> Regards,
>
> Christian
>
> <originalPosting>
> Hi John,
> Let me see if I can shed some light on the key, unique and keyref issue.
>
> I'm trying to decipher the schema spec on identity contstraint validity, but
> perhaps someone can save me a few hours and a few aspirin.
> If I have:
> <keyref name="ref" refers="pk" > ...
>
> 1. Is the key "pk" required to be defined physically earlier in the schema
> file (I would have thought not)
>
> No, the key declaration doesn't need to be declared physically before the
> keyref declaration. The rule is that the scoping element for the key (or
> unique) declaration must be the same as OR a descendant of the scoping
> element for the keyref declaration.
> This means that the following is correct (not complete XML Schema syntax!):
> <xs:element name="root">
>
>    <xs:element name="sub" type="whatever">
>       <xs:key name="key">
>          <xs:selector xpath="key"/>
>          <xs:field xpath="@id"/>
>       </xs:key>
>    </xs:element>
>
>    <xs:keyref name="keyref" refer="key">
>       <xs:selector xpath="keyref"/>
>       <xs:field xpath="@ref"/>
>    </xs:keyref>
>
> </xs:element>
>
> The scoping element for the key declaration is a descendant of the scoping
> element for the keyref declaration.
>
> However this is not allowed:
>
> <xs:element name="root">
>
>    <xs:element name="sub" type="whatever">
>       <xs:keyref name="keyref" refer="key">
>          <xs:selector xpath="keyref"/>
>          <xs:field xpath="@ref"/>
>       </xs:keyref>
>    </xs:element>
>
>    <xs:key name="key">
>       <xs:selector xpath="key"/>
>       <xs:field xpath="@id"/>
>    </xs:key>
>
> </xs:element>
>
> 2. Is pk required to be defined on the same element as ref, or on a
> descendant or anscetor of it, or just anywhere in the same schema?
> The same as OR a descendant.
> Cheers,
> /Eddie
>
> </originalPosting>