Two more use-cases that are both relevant and quite frequent:

  1. An xsl:template or an xsl:function producing more than one result
(or one, but complex result).

  2. Multiple-step processing, where some results of stepK are used in
step(K+X1), other results in step(K+X2), ..., etc. None of the "single
step transformations" knows about the existence of other "single step
transformations"


Cheers,
Dimitre.


On Sun, 2 Jan 2005 17:41:09 +1100, Dimtre Novatchev
<dnovatchev@xxxxxxxxx> wrote:
> It is a common XSLT processing scenario that some intermediate results
> are produced and must be used later during the transformation.
> 
> These results are typically stored within a node-set. Especially for a
> sequence of atomic values, there is no way of representing it
> "natively in XML" -- one has to wrapp every item in a node or contrive
> some other scheme such as coding the sequence as a pipe-delimited
> string.
> 
> Things are even worse with a result, which is a node-identity (as
> opposed to a copy of a node)... To preserve this some kind of a key is
> necessary, such as one that matches a node using its generate-id().
> 
> Because as described the type of the result is generally lost when
> stored in such an intermediate structure, it is often difficult or
> impossible to use them correctly, when they are later reconstituted
> and used.
> 
> For example, after such storage and re-activation an integer will
> become a string and this will affect how it is processed -- comparing
> it to another xs:integer with the value comparison operators will
> raise a type error, while using the general comparison operators will
> result either in a string comparison or in an integer comparison,
> depending on which operand is first.
> 
> Certainly, this is not something new -- we know that XPath 2.0 made
> only the first step to a powerful enough type system.
> 
> A simple way to overcome some of these difficulties will be a
> function, which given an item returns it type -- e.g. the string
> "xs:integer"
> 
> Of course, ideally one would want a "type class" which captures the
> "signature" of a type, such as its constructor functions, its
> orderness (or lack of such), its "eq" and "gt" functions, its
> supertypes, etc.  While this may be considerably difficult to provide
> in XPath 2.0, the simple function I described will suffice for many
> scenarios.
> 
> My question: is it possible and how to implement this function.
> 
> Cheers,
> Dimitre Novatchev.