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:*[1]">
<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:*[1]">
<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:*[1]">
<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