The WGs decided not to make the language introspective (or to provide access
to metadata) this time round: types are not objects and there is no way of
finding information about them.

The closest thing available is the "instance of" operator which allows you
test whether a value is an instance of a known type.

There were moves to add an accessor function to get the actual type
annotation of a node (or an atomic value, perhaps) but the WG decided
against - I'm afraid I don't recall the detailed rationale. Saxon does
provide an extension function saxon:type-annotation() for this purpose. At
some time I might well experiment with further extensions to make schema
information available.

Michael Kay
http://www.saxonica.com/

 

> -----Original Message-----
> From: Dimtre Novatchev [mailto:dnovatchev@xxxxxxxxx] 
> Sent: 02 January 2005 06:41
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: [xsl] [XPath/XSLT 2:0] How to determine the type of an item ?
> 
> 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.