Re: Re: XPath 2.0: Problems with the two boolean const
Hi Jeni! Shall I tell you how glad I feel that finally somebody understands what I'm talking about. > > Therefore, I am forced to remove the types for the parameters of the > > template and do the conversion myself: > > > > <xsl:template name="And" match="test:*"> > > <xsl:param name="arg1"/> > > <xsl:param name="arg2"/> > > <xsl:value-of > > select="xs:boolean(xs:boolean($arg1) and > xs:boolean($arg2))"/> > > </xsl:template> > > Well, only if that's how you choose to solve the problem. Yes, I have to choose between this solution and what you suggest as an alternative: There is another way, though -- > you can pass values that are implicitly castable to xs:boolean, as in: > > <xsl:apply-templates select="document('')/*/test:*"> > <xsl:with-param name="arg1">false</xsl:with-param> > <xsl:with-param name="arg2">true</xsl:with-param> > </xsl:apply-templates> > > or even: > > <xsl:apply-templates select="document('')/*/test:*"> > <xsl:with-param name="arg1"> > <xsl:value-of select="'false'" /> > </xsl:with-param> > <xsl:with-param name="arg2"> > <xsl:value-of select="'true'" /> > </xsl:with-param> > </xsl:apply-templates> > > These work because the parameters are set to the document nodes of > temporary trees, the typed value of the document node is of type > xdt:untypedAtomic, and xdt:untypedAtomic values can be cast to the > required type implicitly, using the normal casting rules (i.e. the > xs:boolean() function). > > In other words, if you want to get implicit casting to a required > type, you should go via xdt:untypedAtomic values (which are most > easily accessible as the typed values of document nodes or text nodes) > rather than xs:string values. > Yes, but working with element (nodes) is generally less efficient than passing simple values. I am 2/3 through a major re-write of FXSL for XSLT2. List represenatation by a node-set is (99.99%) gone, replaced by sequences. The templates and their usage is much more ellegant now, all templates that can be referenced by the user are now xsl:function elements. The code looks much more ellegant (even aesthetically appealing) now and the individual xsl:function s are shorter than the corresponding templates. However, the stylesheet files may be longer now, as I have to model default values by having several versions of the same named function but with different arity. If there's interest I can post some code even before the next release. Nodes would still have to be used for passing implicitly castable values and for representing a sequence, whose items may be sequences themselves. For example I have a function: partition($seq, $funPredicate) which must return two sequences -- the subsequence of $seq, the elements of which satisfy $funPredicate and the subsequence of $seq containing the rest of its items. Ideally the function would return a sequence of two items, which are sequences themselves, however this is not possible with the current XPath 2.0 data model. Therefore, I have to represent a pair of sequences either as a node-set of two elements, the children of each holding the items of each of the two sequences, or as one sequence, started by the first sub-sequence and ended by the second sub-sequence, and having a special delimiter-item (e.g. NaN) between the two subsequences. Unfortunately, the current FO does not provide for an efficient handling of the second representation of the result. So, to return to the original problem, in this case I will prefer to keep the ugly explicit conversion code and not go to using nodes for the parameters. This is because I believe that this situation arises only for the xs:boolean type and I will not have problems with other types, whose values are not artificially represented as some representational (for display) strings. BTW, having: <xsl:apply-templates select="document('')/*/test:*"> <xsl:with-param name="arg1"> <xsl:value-of select="$myArg1" /> </xsl:with-param> <xsl:with-param name="arg2"> <xsl:value-of select="$myArg2" /> </xsl:with-param> </xsl:apply-templates> is equivalent to doing the implicit conversion myself in the instantiated tempalte -- I still write the above manually. Of course, I will write the above only one time and will save writing type-conversion code in hundreds of templates that are instantiated. Still, if there were "real boolean values" like the (0, 1) as opposed to the "artificial, representation-only values" 'true' and 'false', and if only the "real boolean values" were allowed, then this problem would not have existed. This is what I have been repeating in all my messages in this thread. ===== Cheers, Dimitre Novatchev. http://fxsl.sourceforge.net/ -- the home of FXSL __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
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