RE: [xsl] How recursively iterate over entire document?

Subject: RE: [xsl] How recursively iterate over entire document?
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Fri, 12 Aug 2005 00:12:20 +0100
Actually, I don't think this is quite so impossible. Given the evaluate()
and node-set() extensions, it seems quite feasible to write a recursive
process that reads an XPath expression, creates a new tree that modifies the
nodes selected by that expression in some way, and then continues by reading
the next XPath expression to create another new tree and so on. Whether it's
a good application design is another matter, but I don't think it's
infeasible.

Michael Kay
http://www.saxonica.com/
 

> -----Original Message-----
> From: Wendell Piez [mailto:wapiez@xxxxxxxxxxxxxxxx] 
> Sent: 11 August 2005 23:29
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [xsl] How recursively iterate over entire document?
> 
> 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