"Michael Kay" <mike(_at_)saxonica(_dot_)com> wrote in message
news:E1Cb53T-0001Jc-00(_at_)ukmail1(_dot_)eechost(_dot_)net(_dot_)(_dot_)(_dot_)
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.
This is exactly what I am saying -- the type of "/" is "hardwired"
into any XPath implementation. If someone decides to provide an
implementation (or simulation) of a higher-order function such as
map(), there is no good way to express well its type with the
linguistic means of XPath/XSLT.
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.
It seems to me that you're saying there's no constraint on order, not
on duplicates.
It seemed to me that both constraints would be in force for any LHS
operand, because it happens that at the same time this LHS operand is
also the RHS operand of the preceding from left "/".
I am reading from "XPath 2.0 Programmer's Reference" on page 208 the
second bullet bottom-up:
"Each time E2 is evaluated, it produces a sequence of nodes (if it
doesn't a type error is reported). All the nodes produced when E2 has
been evaluated once for every node in S1 are bundled together into a
single sequence. Duplicate nodes are then removed, and the remaining
nodes are sorted into document order."
Because every E1 is also some E2 for another "/", then the above
applies fully for this E1, too -- in fact it has been first evaluated
as an E2 and only then it serves as an E1 for the next "/".
Sorry, if I misunderstood this explanation.
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
Yes, what we're talking here is that if appropriate facilities exist
then the checking can be done at compile time as this is done in some
other languages.
Cheers,
Dimitre.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--