Subject: RE: Future XSLT expansion. From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Sun, 19 Mar 2000 09:51:10 -0500 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: OLD XSLT NAMESPACE, Steve Muench | Thread | Re: Future XSLT expansion., David Carlisle |
Re: useful software?, Jon Smirl | Date | RE: Future XSLT expansion., Didier PH Martin |
Month |