ctA029.xsd (test case)

I'd like clarification on this test case which was initially faulted by Stanley Guan of Oracle where he states 
 "The expected result for the following test case ctA029 should be valid:
    Declaration with optional attribute id = 'foo123' , an included object with
    and id='foo123'
    because the checking for uniqueness is within each document! Am I right?

which spawned the following thread 
> -----Original Message-----
> From: Henry S. Thompson [mailto:ht@cogsci.ed.ac.uk]
> Sent: Friday, March 15, 2002 1:30 AM
> To: Dare Obasanjo
> Cc: Stanley Guan; Schema XML
> Subject: Re: ctA029.xsd (test case)
> "Dare Obasanjo" <dareo@microsoft.com> writes:
> > >From reading the information on ID information items[0] in the XML
> > Schema Structures recommendation it does look like uniqueness is
> > supposed to apply to all IDs in the entire schema after validation 
> > (which includes imported/included schemas).
> > 
> > 
> > [0] http://www.w3.org/TR/xmlschema-1/#e-ii_table
> Sorry, I don't see how you're getting that.  A schema
> document is validated by a schema (the schema for schemas) in 
> the normal way.  The xs:ID type is as close a reconstruction 
> of the ID type in XML 1.0 as possible, and it applies to 
> individual documents.  I don't see anything at the place you 
> reference that suggests ID uniqueness is applied to schemas, 
> as opposed to schema documents.
The XML Schema recommendation states that a set of ID/IDREF binding information items is associated with the ·validation root· element information item[0]. Where the validation root is defined as the element information item at which ·assessment· began[1].  
For a validation root to be valid with regards to ID?IDREFs the recommendation states[2]
"1 There must be no ID/IDREF binding in the item's [ID/IDREF table] whose [binding] is the empty set. 
2 There must be no ID/IDREF binding in the item's [ID/IDREF table] whose [binding] has more than one member."
Looking at the (2) above we see that [binding] should have only one member, so we look at  its description[3] 
A set consisting of every element information item for which all of the following are true
1 its [validation context] is the ·validation root·; 
2 it has an attribute information item in its [attributes] or an element information item in its [children] which was ·validated· by the built-in ID simple type definition or a type derived from it whose [schema normalized value] is the [id] of this ID/IDREF binding." 
Followed by 
"The net effect of the above is to have one entry for every string used as an id, whether by declaration or by reference, associated with those elements, if any, which actually purport to have that id. See Validation Root Valid (ID/IDREF) (§3.3.4) above for the validation rule which actually checks for errors here. "
The only place where it looks like there may be wiggle room to state that ID/IDREF table for the PSVI should not contain duplicate entries for if multiple values of an id exist across schema documents is investigating the term [validation context] which is described as[4] 
"The nearest ancestor element information item with a [schema information] property (or this element item itself if it has such a property)." 
where one assumes that the term "ancestor element information item" implies that such an element must be a child of the <schema> element. However this is countered by looking at the [schema information] which contains namespace schema information items which contains  [schema documents]. Thus implying that multiple documents from a single namespace all share the same PSVI information (including ID/IDREF table). 
[0] http://www.w3.org/TR/xmlschema-1/#sic-id
[1] http://www.w3.org/TR/xmlschema-1/#key-vr
[2] http://www.w3.org/TR/xmlschema-1/#cvc-id
[3] http://www.w3.org/TR/xmlschema-1/#iib-binding
[4] http://www.w3.org/TR/xmlschema-1/#e-validation_context
[5] http://www.w3.org/TR/xmlschema-1/#e-schema_information

This posting is provided "AS IS" with no warranties, and confers no rights. 
You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.


Received on Wednesday, 20 March 2002 16:39:59 UTC