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

Re: [xsl] [XPath/XSLT 2:0] How to determine the type of an item ?

Subject: Re: [xsl] [XPath/XSLT 2:0] How to determine the type of an item ?
From: Dimtre Novatchev <dnovatchev@xxxxxxxxx>
Date: Mon, 3 Jan 2005 07:24:53 +1100

On Sun, 2 Jan 2005 16:49:09 -0000, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> 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.

But this will only return the type annotation -- that is, only if the
document has been validated against a schema and given the type by the
validation process.

The case I describe is to be able to get the type of intermediate
results that are passed as parameters to a generic  xsl:function or
xsl:template expecting item()*

> 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.

Are there any chances that a standard function:


can still be included in XPath?

> 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.

Current Thread