OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Use xsd to specify multiple instances of existing element

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 

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 
<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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS