[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
My question was not as clear as it should have been, though I'm not sure it'll be different this time :-(
The input tree for the transformation depends on values of attributes (at least in this case, we also use external parameters). Our concern was that we may not have full control over a tree that is dynamically constructed.
The example I gave above actually did the trick, but I have some concerns about to what level we can use constructions like these.
We may also want to use "conditional xsl" in the future. The approach you give (unconditionally import etc) is probably the technique we have to use as well.
Too bad you can't "sub-render" conditional xml entities before you insert them in the actuall output tree.
Or can you?
Rh
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
conditional inclusions2
Subject: conditional inclusions2 From: Ronald <ronald@xxxxxxxxxxx> Date: Wed, 1 Nov 2000 09:57:28 -0400 (EST) |
Thanx for your reply Dylan and yes U'r so right. We mixed up a couple of things here.Apologies if I'm wrong, but there may be some confusion on your part. If you wish to use *data* in other files as the source of your transformation, you use the document() function. There is more on this function in the FAQ or Michael Kays book (an essential purchase, by the way). On the other hand, import or include are used in XSL *to bring in other XSL*. Your use of the ".xml" suffix in your examples suggests you want to bring in data.
If in fact you are trying to bring in XSL code, the following may be helpful: Both xsl:include or xsl:import must be top level elements in the XSL file (as an aside, they differ only in the way they handle import precedence). Therefore they cannot be part of a conditional construct as they must be children of the xsl:stylesheet element (or its synonym xsl:transformation), and you cannot put them in an xsl:choose or xsl:if.
The approach I have used in a recent project is to *unconditionally* import all the other stylesheets, and use them *conditionally*. So the correct template(s), once imported, are invoked inside conditional statements using xsl:apply-templates or xsl:call-template.
What I'm actually now doing is something like: <xsl:template match="if"> <xsl:choose> <xsl:when test="@include='1'"> <xsl:apply-templates select="document('file1.xml')"/> </xsl:when> <xsl:otherwise> <xsl:apply-templates select="document('file2.xml')"/> </xsl:otherwise> </xsl:choose> </xsl:template>
My question was not as clear as it should have been, though I'm not sure it'll be different this time :-(
The input tree for the transformation depends on values of attributes (at least in this case, we also use external parameters). Our concern was that we may not have full control over a tree that is dynamically constructed.
The example I gave above actually did the trick, but I have some concerns about to what level we can use constructions like these.
We may also want to use "conditional xsl" in the future. The approach you give (unconditionally import etc) is probably the technique we have to use as well.
Too bad you can't "sub-render" conditional xml entities before you insert them in the actuall output tree.
Or can you?
Rh
---------||-------||----------- Ronald Heller Salience BV Villawal 21 3432 NX Nieuwegein tel.: 030 60 56 675 fax: 030 6056 324 mob.: 06 20 41 25 77 ronald@xxxxxxxxxxx www.salience.nl
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Newsgroups vs. Mailing Lists (was: , David_Marston | Thread | Re: conditional inclusions2, Jeni Tennison |
Newsgroups vs. Mailing Lists (was: , David_Marston | Date | <saxon:output> throws "NoSuchMethod, Ron Chibnik |
Month |