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

Re: [xsl] Looking for a shorter mapping expression

---

---

"Michael Kay" <mike@xxxxxxxxxxxx> wrote in message
news:E1Cb53T-0001Jc-00@xxxxxxxxxxxxxxxxxxxxxx
>> 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.

---