RE: Future XSLT expansion.

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

Hi Jon,

Jon said:
Variables have always been able to contain structured content. The problem
is not with the variable definition it's with the <xsl:apply-template
select="$variable"/>. In my case the variable contains a result set fragment
and it's not legal to implicitly convert a result set fragment into a
node-set. I would need this: <xsl:apply-template
select="node-set($variable)"/>. Allowing this in the core would break the no
side effect rule.

Didier replies:
I know Jon and I understand that your comment was about this. Just as a
reminder here is the extract referred in the last post.

<extract>
If the variable-binding element does not have a select attribute and has
non-empty content (i.e. the variable-binding element has one or more child
nodes), then the content of the variable-binding element specifies the
value. The content of the variable-binding element is a template, which is
instantiated to give the value of the variable. The value is a result tree
fragment equivalent to a node-set containing just a single root node having
as children the sequence of nodes produced by instantiating the template.
The base URI of the nodes in the result tree fragment is the base URI of the
variable-binding element.
</extract>

My interpretation of the text above is that because the variable element can
have one or more children, we then have PCDATA with mixed content. This
means, therefore that we have here structured content. Then, if this element
allows to have structured content, this is translated into node set. If the
element results into a node set the construct <xsl:apply-templates
select="{$variable}"/> is OK since we process here a node set. So, the main
point here is that the specs (If I understood well) state that a variable
can contain a node set "the value is a result tree fragment equivalent to a
node-set containing just a single root node having as children the sequence
of nodes produced by instantiating the template".

So, maybe I didn't understood it well but it is my understanding that the
result tree for an expression like

<xsl:variable name="bunny">
	<address>
		<street>Holmer street</street>
		<city>Underground city</city>
		<country>rabbitland</country>
	</address>
</xsl:variable>

would be translated into the following tree fragment

bunny
  |___ address
 	    |__ street
	    |__ city
	    |__ country

and that the apply-template construct ca be applied to this tree fragment
and templates matched with its content. As stated, the variable construct is
a single rooted tree. It is my understanding that the root is the variable
and thus only a single rooted tree is created with the xsl:variable
construct. In constrast to usual node sets which allows to have a collection
of fragment trees, the variable allows to create a single rooted fragment
tree.

Thus, it is also my understanding that applying templates to the result tree
is valid and conformant to the specs. But, as I said, I may be wrong. But it
is my understanding that the apply-templates is a valid construct that can
be applied to a variable and therefore the node-set extension is not
necessary since we should have what we want to get.

If I understand well your point. It is that actually the result tree is an
other type not identical to the node set and that the result tree cannot be
used by the apply-template. Hence the casting into a node set with the
node-set construct. So, if an implementation make the result tree type is
equivalent to the node set or said differently that the xsl:apply-templates
construct can be equally applied to node set and result set or simply that
result set are simply single rooted node set and that they are processed the
same way (i.e. equivalent). This would imply that result tree is simply a
node set with a single element.

Conclusion: Now the question is: Can an implementer implement the result
tree simply as a single member node set and thus have result trees processed
as node sets. If this is so, is it compliant to the recommendation.

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@xxxxxxxxxxxxx
Conferences: Web Chicago(http://www.mfweb.com)
             XML Europe (http://www.gca.org)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com

> But I may be wrong and it is better if somebody else would check and
double
> check the specs to bring some more light. So that we can update our FAQ
> and conformance tests.

A while ago I exchanged direct email with James Clark that indicated that it
is indeed not legal to convert the contents of a variable into a node-set.
His response was that's what document('') is for. I did find this to be
non-obvious but it does work and XT is correct.

> "Variables introduce an additional data-type into the expression language.
> This additional data type is called result tree fragment. A variable may
be
> bound to a result tree fragment instead of one of the four basic XPath
> data-types (string, number, boolean, node-set). A result tree fragment

In another conversation we determined that there is a fifth XPath data type.
It's is an opaque variable datatype. Check the source of XT and you'll find
five datatypes. For example you can use extension functions to select a Java
class instance into an XSL variable. XSL can do nothing with the contents of
the variable except to pass it back to an extension function. I use this
feature to compute running totals efficiently.

Jon Smirl
jonsmirl@xxxxxxxxxxxx



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


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