Subject: RE: [xsl] [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 |
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.
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] [XPath/XSLT 2:0] How to deter, Dimtre Novatchev | Thread | Re: [xsl] [XPath/XSLT 2:0] How to d, Dimtre Novatchev |
Re: [xsl] end-of-sentence full stop, Ian Tindale | Date | RE: [xsl] XPath 2.0 conditional exp, Michael Kay |
Month |