Re: Future XSLT expansion.

[Paul Tchistopolskii <paul@xxxxxxx>]

----- Original Message ----- 
From: Jon Smirl <jonsmirl@xxxxxxxxxxxx>


> From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
> > So, always if I understood the text well (we are never sure with specs
> :-))
> > and if my lawyer says that we have jurisprudence here :-)) then, it seems
> > that yes a variable element can contain structured content and not only
> > strings.
> 
> Variables have always been able to contain structured content. 

Sure. 

> 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.

*Sometimes*. It could *sometimes* have side-effect.
The same problem is why 'eval' is forbidden,  I think.

> 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.

Yes, because when typecasting is done with the document() hack 
one could be sure that there will be no side-effects, because 'documents'
are not 'mutable', but variables could be. If the variable has no <xsl:***>
things inside, what is the difference between the 'variable' and 'XML file' ?
No differences, I think. Right?

The workaround  could be  :  

1. ( simple). Fire the typecast expection if the variable which is 
typecasted to node-set has any sign of mutability inside of it 
( <xsl: construction) but not *always* fire that exception, like it is 
now.

2.  (hard)  always re-instantiate the variable template
at the moment of node-set typecast of the variable. 

Implementing (1) is trivial. XSLT is simply limiting here without 
any reason, I think.

Again: there is no serious difference between :

a. Take some structured content with document() function.
b. Typecast that content into node-set()    
( the current semantics of 'document()' )

and 

a. Place some structured content between 

<xsl:variable name="var>
<foo><bar/><foo>
</xsl:variable>
 
b. Typecast that content into node-set;

The 'possible-side-effect' problem appears when  there are some 
other constructions in there.

<xsl:variable name="var">
<foo><bar/>
<xsl:something -here-et.c./>
<foo>
</xsl:variable>

But I think the forced instantiation of the entire body of  "var" and the moment 
of explicit node-set typecast will cause no problems, side-effects e t.c.

Conclusion. Allowing hidden node-set typecast for document() but not 
allowing it for variables is just yet another limitation in the XSLT core wich 
has not too much reason behind it.  

> > "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.

... non-standard and non-portable trick ... Right? As I have been told - 
you should not do that with XSLT. 

Specs says that  XSLT Is for processing XML files ( which are node-sets
by definition ) and that fifth XPath dadatype is not XML, so you should 
not use that thing. 

Just kidding - thank you for your letter, I wish things are now a bit more clear
for all of us. 

Rgds.Paul.

PS. 

Ah, of course this letter is not about the <xsl:variable>. It is all still 
about the 'sources which are not XML node-sets'  

Of course, <xsl:variable> is just yet another  example of such a source.




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