W3C home > Mailing lists > Public > xmlschema-dev@w3.org > September 2005

key-keyref constraints: conflicts in node-table

From: Michael Kay <mike@saxonica.com>
Date: Mon, 26 Sep 2005 14:58:36 +0100
To: <xmlschema-dev@w3.org>
Message-ID: <E1EJtVH-0000uR-N2@maggie.w3.org>

I'm trying (once again) to understand the complexities of the "node-table"
concept in defining the rules for key-keyref. (Schema Part 1, 3.11.5). In
particular this provision:

provided no two entries have the same .key-sequence. but distinct nodes.
Potential conflicts are resolved by not including any conflicting entries
which would have owed their inclusion to clause 1 above. Note that if all
the conflicting entries arose under clause 1 above, this means no entry at
all will appear for the offending .key-sequence..

At present Saxon implements the rather simpler rule: (informally) it's an
error if a keyref matches more than one node with the same key. The actual
rule seems to be that it's an error if a keyref matches more than one key,
unless one of these keys appears at the same level of the hierarchy as the
keyref itself.

I'm having great trouble constructing an example that illustrates this
distinction. Was there some use-case that motivated using the more complex

Here's an attempt: SECTIONs contain SECTIONs, DEFINITIONs, and TERMREFs.
There's a key on SECTION specifying selector xpath="DEFINITION" field
xpath="@term", and there's a keyref on SECTION specifying selector
xpath="TERMREF" field xpath=".". This means that DEFINITIONs are required to
be unique only if they are siblings: they can conflict with cousins or
nephews. A TERMREF must match a DEFINITION anywhere (at any depth) in the
immediately containing SECTION. It isn't allowed to match two different
DEFINITIONs (of the same term), unless one of them is an immediate sibling
of the TERMREF, in which case it doesn't matter how many other matching
DEFINITIONs there are.

Have I got that right? 

Michael Kay
Received on Monday, 26 September 2005 13:58:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:08 UTC