[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
Two more use-cases that are both relevant and quite frequent: 1. An xsl:template or an xsl:function producing more than one result (or one, but complex result). 2. Multiple-step processing, where some results of stepK are used in step(K+X1), other results in step(K+X2), ..., etc. None of the "single step transformations" knows about the existence of other "single step transformations" Cheers, Dimitre. On Sun, 2 Jan 2005 17:41:09 +1100, Dimtre Novatchev <dnovatchev@xxxxxxxxx> wrote: > 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
|