[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Future XSLT expansion.

Subject: Re: Future XSLT expansion.
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Sat, 18 Mar 2000 14:58:56 -0800
mutable nodeset xsl
----- 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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.