Re: [xml-dev] Use xsd to specify multiple instances of existing element

[Rick Jelliffe <rjelliffe@allette.com.au>]

Andrew Welch wrote:
>> The conditional way does not seem to meet Ian's order constraint. So I think
>> the assertions are the
>> only mechanism for XSD 1.1 for Ian's particular problem.
>>     
>
> unless you can do:
>
> <xs:alternative type="element-that-must-be-first" test="position() eq 1"/>
> <xs:alternative type="element-that-must-be-second" test="position() eq 2"/>
> <xs:alternative type="rest" test="position() gt 2"/>
>
> I don't know if that's possible...
On my reading, it is not allowed.

A defined subset of XPath 2 is allowed. In XSD 1.1 draft 3.12.6 list 
item 3, it seems that you can only have functions that evaluate the 
static context.  (The text here uses idioms that are not clear to me, so 
it may mean almost anything else, don't shoot me.)  Context position is 
in the dynamic context, not the static context.

In XSD assertions, it seems that position() is not disallowed by the 
text but is inconsistent against other requirements:

In XQuery and XPath 2 Data Model s2.4 "The relative order of siblings is 
the order in which they occur in the *children* property of their parent 
node."  So, nominally, to look up the position requires checking the 
parent.

However, in XSD 1.1 s3.1.3.1 "Path steps are restricted to only match 
information items within the element being ·assessed· 
<http://www.w3.org/TR/2008/WD-xmlschema11-1-20080620/#key-va>. XPath 
predicates 
<http://www.w3.org/TR/2007/REC-xpath20-20070123/#dt-predicate> are 
restricted to only match information items within the element on which 
the predicates 
<http://www.w3.org/TR/2007/REC-xpath20-20070123/#dt-predicate> are applied."

So the intent of the spec is that you only have downward looking XPaths, 
not parent or siblings. But the context position formally requires a 
backwards look to the parent's children property, but this is disguised 
in the steps because while it may need to look at the parent, the parent 
is never actually made a location step; the access to the parent 
information item is cloaked by syntax, which may or may not be 
deliberate. So the old XSD rule obtains: try your implementation and see 
what works: try multiple implementations to see if it is portable.

But XSD 1.1 is still a draft, so caveat emptor.

Cheers
Rick