[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] 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/

---