Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


key-keyref constraints: conflicts in node-table

From: "Michael Kay" <mike@--------.--->
To: <xmlschema-dev@--.--->
Date: 9/26/2005 3:59:00 PM
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
rule? 

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
http://www.saxonica.com/



From K.Buchcik@4... Mon Sep 26 18:52:37 2005
Received: from li


transparent
Print
Mail
Digg
delicious
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent