xsl-list
[Top] [All Lists]

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

2005-01-02 09:49:09
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(_at_)gmail(_dot_)com] 
Sent: 02 January 2005 06:41
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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.

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--




--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



<Prev in Thread] Current Thread [Next in Thread>