This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

conditional inclusions2



>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.
Thanx for your reply Dylan and yes U'r so right. We mixed up a couple of 
things here.

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@salience.nl
www.salience.nl




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]