[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Chris,
What you are trying to accomplish in a single pass defies the processing model for XSLT 1.0. If you could map out the dependencies between the different settings explicitly, it might not be completely inconceivable under XSLT 2.0, but it's not a task I'd relish. I'd probably be inclined to start with the assumption that N passes over the data may be needed, where N is the number of assertions you are making.
While evaluate() may be handy, I'd suggest you try thinking through how you'd do this without it -- writing a stylesheet to generate stylesheets. You could, in fact, generate a suite of stylesheets to be executed consecutively over your data in a (longish) pipeline (they'd all be variants of the identity transform, except amended with logic from your settings). This would have the virtue of clarifying the dependencies. Your process expects x to happen before y -- but the XSLT processing model doesn't support that specification explicitly (it's designed so processors can execute steps in parallel if they like).
This is sort of like trying to repair your engine while your car is moving at 65mph on the highway.
At 06:04 PM 8/11/2005, you wrote:
Re: [xsl] How recursively iterate over entire document?
Subject: Re: [xsl] How recursively iterate over entire document? From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Thu, 11 Aug 2005 18:29:15 -0400 |
Chris,
What you are trying to accomplish in a single pass defies the processing model for XSLT 1.0. If you could map out the dependencies between the different settings explicitly, it might not be completely inconceivable under XSLT 2.0, but it's not a task I'd relish. I'd probably be inclined to start with the assumption that N passes over the data may be needed, where N is the number of assertions you are making.
While evaluate() may be handy, I'd suggest you try thinking through how you'd do this without it -- writing a stylesheet to generate stylesheets. You could, in fact, generate a suite of stylesheets to be executed consecutively over your data in a (longish) pipeline (they'd all be variants of the identity transform, except amended with logic from your settings). This would have the virtue of clarifying the dependencies. Your process expects x to happen before y -- but the XSLT processing model doesn't support that specification explicitly (it's designed so processors can execute steps in parallel if they like).
This is sort of like trying to repair your engine while your car is moving at 65mph on the highway.
Cheers, Wendell
At 06:04 PM 8/11/2005, you wrote:
Hi List, It's kind of strange what I'm doing, so it's hard to explain. I'll try to keep it simple. In my document that I'm trasnforming, I have a sequence of elements that contain some xpath queries in them.... that will be dynamically evaluated using evaluate(). These can't be evaluated consecutively on the same document, because one will cause changes to the document that the next one has to see, etc.
So in other words, I need to iterate over a sequence and for each iteration, make changes to a document and pass it on to the next iteration. In the end, I want only the single document with all the changes to it. I'm probably making no sense, so I'll try to illustrate and example.
Source Documents ------------------------------ <settings> <setting xpath="/company/departments"> <department name="c"/> </setting> <setting xpath="/company/departments/department[@name='c']"> <employees count="10"/> </setting> </settings>
<company> <departments> <department name="a"/> <department name="b"/> </departments> </company>
Output Doc ------------------------------ <company> <departments> <department name="c"> <employees count="10"/> </department> <department name="a"/> <department name="b"/> </departments> </company>
---------------------------
Please ignore the worthlessness of this example... it's just a simplified example to illustrate what I'm trying to do. As you can see, the first 'setting' element is adding a new element to the doc at the location specified by the 'xpath' attribute. I have no problem with doing just one. The problem I have, is that the second setting element has an xpath that is depended on the first one already having been completed because, for example, department C does not exist until it has been added.... and since this is not DOM, it's getting a little complicated for me to conceptualize how to do this...
This doesn't work, but maybe will give some ideas....
<xsl:variable name="doc" select="document(company.xml)"> <xsl:for-each select="settings/setting"> <xsl:variable name="doc"> <xsl:apply-templates select="$doc"> (tunnel setting element param...) </xsl:apply-templates> </xsl:variable> </xsl:for-each> <xsl:sequence select="$doc"/>
Any ideas?
Thanks!
====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] How recursively iterate over , chris | Thread | Re: [xsl] How recursively iterate o, chris |
RE: [xsl] How to transform a huge X, Michael Kay | Date | Re: [xsl] How recursively iterate o, chris |
Month |