Re: keyref to a key in a different scope

George Cristian Bina writes:

>         <xs:element name="child" maxOccurs="unbounded">
>           <xs:complexType>
>             <xs:sequence maxOccurs="unbounded">
>               <xs:element name="element">
>                 <xs:complexType>
>                   <xs:attribute name="id" use="required"/>
>                 </xs:complexType>
>               </xs:element>
>             </xs:sequence>
>           </xs:complexType>
>           <xs:key name="k">
>             <xs:selector xpath="element"/>
>             <xs:field xpath="@id"/>
>           </xs:key>
>         </xs:element>

Fools rush in . . .

The place to start is with the above element decl.  _All_ it claims is
that within the scope of a <child>, <element>s are uniquely keyed by
their @id.

Think (modern) families -- you might well have a similar declaration
which asserted that within the scope of a <family>, <offspring>s are
uniquely keyed by their @forename.

So what does it mean to try to reference an <element> (respectively
<offspring>) by its @id (respectively, @forename) from outside the
scoping <child> (respectively <family>)?

XML Schema could have said "Bzzzt.  Incoherent." and disallowed such
keyrefs altogether.  Instead, it specified that key bindings would
float upwards, with any multiple bindings for the same key being
eliminated altogether.  The result is that from the perspective of the
higher <parent> context, only 'a2' and 'a4' are visible.

So, net-net, Saxon is correct and Xerces is incorrect, I believe.

This does seem to accord with common sense -- in a context where family1
has two children, Robin and Kim, and family2 also has two children,
Kim and Bryn, then references to Bryn or Robin make sense, but a
reference to Kim does not, if references have to be unique.

The spec. offers [1] the following . . . apology for the complexity of
all this:

  The complexity of the above arises from the fact that keyref
  identity-constraints can be defined on domains distinct from the
  embedded domain of the identity-constraint they reference, or on
  domains which are the same but self-embedding at some depth. In
  either case the ·node table· for the referenced identity-constraint
  needs to propagate upwards, with conflict resolution.

ht

[1] http://www.w3.org/TR/2012/PR-xmlschema11-1-20120119/#sic-key
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Received on Monday, 14 January 2013 13:59:30 UTC