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: 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: [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 -> |
---|---|---|
RE: [xsl] [XPath/XSLT 2:0] How to d, Michael Kay | Thread | [xsl] Re: [XPath/XSLT 2:0] How to d, Dimtre Novatchev |
RE: [xsl] XPath 2.0 conditional exp, Michael Kay | Date | RE: [xsl] counting the no of lines , Jarno.Elovirta |
Month |