Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Use xsd to specify multiple instances of existing element
 > 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/ 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
