Re: [XPath/XSLT 2:0] How to determine the type of an i
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: type-of(someItem*) can still be included in XPath? Cheers, Dimitre. > > 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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format