Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: keyref with empty sets

From: "Michael Kay" <mhk@---.--.-->
To: "'Nigel Hardy'" <nwh@----.--.-->, <xmlschema-dev@--.--->
Date: 5/28/2004 7:12:00 PM
DIfferent schema processors appear to differ on the validity of either of
these documents.
 
The rules for what happens when the xs:key and the corresponding xs:keyref
are defined on different element declarations are incredibly obscure (so
it's not surprising that implementations differ).
 
My reading is that the element on which the keyref appears (ExperimentSet)
is only valid if it has a "node-table" for the referenced key containing
each value selected by the keyref, and such a node-table will exist only for
the element on which the key is defined (UserSet) and on each of its
ancestors. In other words it only makes sense to define a keyref on either
the same element as the key, or an ancestor of it. The ExperimentSet element
doesn't have a node-table for the UserKey key, and I therefore conclude that
the ExperimentSet in d1.xml is invalid; and MSXML 4.0 appears to agree.
However, Xerces and XSV both say this one is valid, so I may well have the
wrong end of the stick.
 
In fact, I almost certainly have got the wrong end of the stick, because
MSXML, Xerces, and XSV all agree that d2.xml is invalid, and I can't for the
life of me see what is wrong with it. One would certainly think that d2 can
only be invalid if the schema is invalid, and if the schema is invalid then
d1 must fail validation. So I look forward to Henry's answer with eager
anticipation... 
 
(I'm particular intrigued to know what the phrase "which much be understood
as logically prior to this clause of this constraint, below" is supposed to
mean. I don't understand it at all, let alone understanding it as logically
prior to something else, below or otherwise.)
 
As I am implementing a schema processor I'm interested in knowing what the
exact rules are, but my advice to a user would be always to declare the key
and the keyref on the same element, to steer clear of these problems. In
your case this is the Admin element.
 
Michael Kay


  _____  

From: xmlschema-dev-request@w... [mailto:xmlschema-dev-request@w...] On
Behalf Of Nigel Hardy
Sent: 28 May 2004 13:56
To: xmlschema-dev@w...
Subject: Re: keyref with empty sets


Henry S. Thompson wrote:


I _think_ I understand your problem, but a complete schema and an

instance that illustrates the problem would allow me (and others) to

try to replicate. . .



  

Thank you very much. 

*	mod-admin.xsd is the schema 

*	it uses datatypes.xsd so I have added that 

*	d1.xml works (probably you don't need that example therefore) 

*	d2.xml causes the problem 

As you will guess for the filename, admin is only a module of a larger
system, hence the reason for allowing it to be empty.

Nigel

-- 

---------------------------------------------------------------------

Nigel Hardy     Tel: +44 1970 622 434.   http://users.aber.ac.uk/nwh/

  Dept. Computer Sci,  University of Wales, Aberystwyth, SY23 3DB, UK

  Adran Cyfrifiadureg, Prifysgol Cymru,     Aberystwyth, SY23 3DB, UK






transparent
Print
Mail
Like It
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