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.