RE: May XSLT - 9.3 Values of Variables and Parameters

> > A variable-binding element may specify the supplied value of the 
> > variable or parameter in four different ways.
> 
> 
> the second bullet uses the condition "has empty content " 
> (without further comment)
> 
> 
> the third uses the presumably inverse condition "has 
> non-empty content" this time further defined as "(i.e. the 
> variable-binding element has one or more child nodes)"
> 
> It would  good  (in both cases, or at least the first case 
> rather than the second:-) to clarify whether the child nodes 
> are counted before or after the white space stripping process 
> that is normally applied to the stylesheet, and whether PIs 
> in the stylesheet are removed (so don't count here) or still 
> there, but just ignored, so do count. I think <xsl:variable 
> name="x"> </xsl:variable> is empty in this context (although 
> it's not EMPTY to an XML parser). This wasn't particularly 
> clear in XSLT 1 either.

I prefer to keep the statement in one place (4.1) that "the stylesheet
module is treated as if the processing instructions and comments were not
there". I'm never all that happy with "as if" formulations (I generally
prefer to define a concept such as "the effective stylesheet" as being "the
actual stylesheet minus comments and PIs"), but I'm even less happy with
scattering this kind of thing around the spec in every place where it might
make a difference - it leads people to wonder why it's expressed differently
in different places. I'll see if the wording can be improved, but keeping it
in one place.

> 
> For the new "as" possibility in the final bullet, one needs 
> to bind the stylesheet more closely to XSD type semantics 
> than is perhaps desirable. Comparing two possibilities 
> recently given on xsl-list
> 
> 
> 
>      <xsl:function name="dp:childCount">
>      <xsl:param name="nm"/>
>      <xsl:sequence 
>        select="avg(for $n in $root//*[name() = $nm] 
>                    return count($n//*))"/>
>      </xsl:function>
>      
>      If you don't want to use the XPath "for" expression 
> (some people dislike
>      writing long XPath expressions) you can do more of the 
> work at the XSLT
>      level:
>      
>      <xsl:function name="dp:childCount">
>      <xsl:param name="nm"/>
>      <xsl:variable name="counts" as="xs:integer*">
>        <xsl:for-each select="$root//*[name() = $nm]">
>          <xsl:copy-of select="count(.//*)"/>
>        </xsl:for-each>
>      </xsl:variable>
>      <xsl:sequence select="avg($counts)"/>
>      </xsl:function>
> 
> 
> The Xpath construct allows a possibly heterogeneous sequence 
> to be constructed without any explicit typing. Whereas the 
> XSLT version requires that an explicit XSD type be given and 
> all values are coerced to that, it also forces that the xsd 
> namespace is declared in the stylesheet.
> 
> One could presumably get the effect of a heterogeneous 
> sequence by specifying a suitably general type such as 
> xs:anyType* (if I spelled that correctly) but this requires 
> knowing more about the type hierarchy than one would wish.

Yes, you can write it as "item()*".

 At 
> least in part it seems that the "as" attribute is just being 
> used as a flag here to stop XSLT 1 style tree construction 
> with an implicit document node, and it doesn't really matter 
> what value is given. If that is it's use it seems a bit hard 
> on the user that they have to know details of XSD type system 
> in order to set this flag. Could XSLT provide a no-namespace 
> synonym such as "sequence" for the most general type, so that 
> if you want a sequence rather than a tree you go as="sequence" ?
> 

I'm a bit uncomfortable myself with this overloading of the "as" attribute,
to act both as a sequence-or-tree switch and as the target data type. We
explored the options at our last meeting but none of the ideas put forward
seemed to make things better. But new ideas are welcome.

Michael Kay

Received on Friday, 13 June 2003 13:56:11 UTC