RE: Looking for a shorter mapping expression
> No, "/" is an XPath operator, which is used in path expressions. It is > also a higher-order operator, whose domain and codomain types are not > defined (XPath has access to the datatypes of nodes -- as found in > PSVI, to the types of variables (from the context if they are > externally passed) , to the types of literals -- constructed during > lexical analysis and to the types of externally defined functions > (like xsl:function) -- as available in the context. > > However, "/" is not externally defined and there do not seem to be any > suitable facilities to describe its type -- either in XSD or those > available in XSLT 2.0. I'm not sure quite what you're trying to say here. It's certainly true that the type system does not allow user-defined higher-order functions or operators to be declared. However, the formal semantics do define the type inferencing rules for "/", as well as for other higher-order operators built in to the language, such as E1[E2] and "for" expressions. > > Its first (left-hand) operand may be any expression evaluating to a > sequence of nodes (generally of differing types ) (sorted by document > order and with no duplicates) and its second operand is even more > unrestricted as it can be a function of any (suitable) type returning > any type (of either a node or an atomic value). Almost right, not quite: the first operand does have to be a sequence of nodes, but there are no constraints on duplicates. For example, it's valid to write (name, address, postcode)/name() and if exactly one of each of these child elements exists, the result will be ("name", "address", "postcode") regardless of the order in which the children appear. Sorting into document order and deduplication of nodes are done for the results of the following expressions: axis steps an expression using the "/" operator that returns a sequence of nodes the union, intersect, and except operators > > What is needed in order to define the type of such functions is a > *type expression*. More specifically, I am not aware of any facility > available in XSLT 2.0 to describe the type of an argument, which > argument is a function -- this is not present, because higher order > functions are not present in the language. Correct. User-defined higher-order functions cannot be defined in XSLT 2.0 or XQuery 1.0. The main reason they were not included in this round was the complexity of the extensions that would be needed to the type system. In Saxon-SA 8.1 I have introduced an experimental extension that enables higher-order functions to be used. The static typing is initially rather weak, in that such functions all have the same type jt:net.sf.saxon.expr.UserFunction, regardless of the arguments they take or the result they return. All the checking is therefore done at run-time. See http://www.saxonica.com/documentation/extensions/functions/function.html Michael Kay http://www.saxonica.com/
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