[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: RE: [XPath/XSLT 2:0] How to determine the type of an item ?
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Sun, 2 Jan 2005 16:49:09 -0000
xpath integer comparison
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:  [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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.