Subject: Re: [xsl] local variables as entity reference in different stylesheets From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> Date: Mon, 3 Dec 2001 22:51:11 +0000 |
Hi Marko, > Well, now that I think of it: I'm as surprised as you are! msxsl-bug? > > This works: > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" > > <xsl:output method="text" encoding="iso-8859-1" /> > <xsl:template match="/"> > <test> <!-- some root element --> > <xsl:variable name="dummy" select="1"/> > </test> > <xsl:value-of select="$dummy"/> <!-- $dummy is known and output will be 1 --> > </xsl:template> > </xsl:stylesheet> Cripes, you're right! That's definitely a bug, in both MSXML 3 and 4. Will you report it? > The XSLT-part is used to create sql-scripts, (selects, inserts, > updates and deletes) which explains why I don't care about result > trees: the output method is text. So the trick here is that the root > element is only used to apply the xsl-namespace. Good. I was thinking of other possibilities before I realised that the root element would give you variable scoping problems, and if you *were* worried about result elements then the best thing would probably be an xsl:if: <xsl:if test="true()" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> ... </xsl:if> (Note that this *doesn't* work with MSXML :) Interestingly enough, with processors other than MSXML (e.g. Saxon, Xalan, libxml) you don't have to worry about the namespace declarations in the external document at all because the entities are resolved before the namespace prefixes are checked. > In fact I already make use of your suggestion to call named > templates to fill them, by starting of each stylesheet with an > <xsl:include href="templates.xsl"/>. I just thought it would be > shorter and less prone to typing errors to use [entity references]. Yes, it probably is. I just think using entities is a bad idea in general because you lose information about them when you process the XML - if you were to run your stylesheets through some other transformation, for example. Thinking along those lines, you could try an approach where you included something like: <my:variables /> in your stylesheets and ran them through another XSLT process to substitute in the variable declarations, and use the result of that transformation as the stylesheet in your later transformations. For a generic language along those lines, you could use XInclude to encode the inclusion, with XPointers that point past the root element in your included document to the variable definitions that you're actually interested in. Of course you'd have to use an XInclude-and-XPointer-aware pre-processor to resolve them. The advantage of entities is that most basic XML parsers will do the job for you. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Re: [xsl] local variables as en, Marko Draisma | Thread | Re: Re: [xsl] local variables as en, Marko Draisma |
RE: [xsl] [ANN] XPathTester 1.4 (Sa, Wendell Piez | Date | [xsl] Filtering when grouping by Me, Magick, Brian |
Month |