Re: [xsl] Re: XPath 2.0: Problems with the two boolean constants true and false

Subject: Re: [xsl] Re: XPath 2.0: Problems with the two boolean constants true and false
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Thu, 9 Oct 2003 12:05:49 +0100
Hi Dimitre,

> Yes, but working with element (nodes) is generally less efficient
> than passing simple values.

That's true or course. I'd suggest passing text nodes rather than
element nodes, if you're just interested in their (untyped) values,
since I imagine that they are represented more efficiently.

(I wondered about suggesting just creating untyped values, but from
what I can tell you can't create them with xdt:untypedAtomic('true');
that function isn't listed in the constructor functions in the F&O
WD.)

> I am 2/3 through a major re-write of FXSL for XSLT2.

Cool.

[snip]
> Nodes would still have to be used for passing implicitly castable
> values and for representing a sequence, whose items may be sequences
> themselves.

Yes, not being able to have sequences as items is irritating in these
circumstances. (It also makes certain parts of XSLT 2.0, such as
grouping, a bit messier than they would be otherwise.)

> 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.
[snip]
> 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.

I don't understand the point that you're making here. All the types
have lexical (string) representations of their values, and there is
never implicit casting from those string representations to the
relevant value. For example, you will get type errors if you have a
template whose parameters are typed as xs:date or xs:double if you
pass strings to those parameters, as in:

  <xsl:template name="AddDateAndDuration" match="test:*">
    <xsl:param name="arg1" as="xs:date"/>
    <xsl:param name="arg2" as="xdt:yearMonthDuration"/>
    <xsl:value-of select="$arg1 + $arg2"/>
  </xsl:template>

with the call:

   <xsl:apply-templates select="document('')/*/test:*[1]">
     <xsl:with-param name="arg1" select="'2003-10-08'"/>
     <xsl:with-param name="arg2" select="'P2M'"/>
   </xsl:apply-templates>

In what way is xs:boolean any different?

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread