[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Future XSLT expansion.
----- 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|