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

["Michael Kay" <mike@saxonica.com>]

> On my reading, it is not allowed.

A call to position() is allowed, but always returns 1. This is because
position() returns the value of context position in the dynamic context,
which is defined in XSD 1.1 section 3.13.4.2 to take the value 1.

I'm afraid it's a common misunderstanding that position() is somehow related
to the number of preceding siblings that a node has.
> 
> 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.  

This is the minimum subset of XPath 2.0 that schema processors must support.
It's my hope that most processors will support the full XPath 2.0 language.
The spec allows this, and that's what Saxon does; perhaps if other
implementations of the draft follow suit, the spec will cease to be so
generous before it goes final. (Note however that although the full syntax
is available, this doesn't make the full input document available: this is
achieved not by restricting the syntax, but by presenting the expression
with a restricted view of the input document).

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

You've completely misunderstood the text here, I'm afraid. The set of
functions available for use in an XPath expression is not defined in the
XPath language spec, it is defined by the static context in which XPath is
used. For example, when XPath is used in XSLT the function library includes
user-defined functions defined in the stylesheet; in XForms it includes some
functions like instance() defined in the XForms spec. The set of available
functions is always known statically, which is why it is considered to be
part of the static context of the expression. The minimal set of functions
that schema processors are required to place in the static context is
(unfortunately) tiny (and does not include position()), but I hope most
processors will take advantage of the ability to support a larger set. Saxon
allows calls to external Java code, so the set of available functions is
effectively infinite.
> 
> 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.

No, position() has nothing to do with siblings.
> 
> So the intent of the spec is that you only have downward 
> looking XPaths, not parent or siblings.

Correct.

> But the context 
> position formally requires a backwards look to the parent's 
> children property,

Wrong.

Michael Kay
http://www.saxonica.com/