This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: how to rearrange nodes based on a dependency graph?
- From: Wendell Piez <wapiez at mulberrytech dot com>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Thu, 20 Dec 2001 18:46:36 -0500
- Subject: Re: [xsl] how to rearrange nodes based on a dependency graph?
- References: <01bc01c189a5$d86a2a50$2100a8c0@swiftnet.tec>
- Reply-to: xsl-list at lists dot mulberrytech dot com
Guenther,
I didn't follow the start of this thread closely, so I can't give a
particular solution, but...
At 05:52 PM 12/20/01, you wrote:
>I still can't see what this would do. This isn't about simply
>filtering out nodes with dependencies, it is filtering out
>those nodes that had already been processed because of the
>dependency graph walk. The only way I can see to do this is
>to somewhere keep a list of the processed nodes, but how
>can I do that with XSL? (I guess I can't).
Right: such an approach would not be The XSL Way. XSLT processing is
designed to be as side-effect free as possible; and unfortunately relying
on the order nodes happen to be processed in a given implementation (or
even relying on the assumption that they will be processed in any order at
all) is considered to be relying on a side effect.
> The only alternative
>would be to decide for every node if it would have been in
>the dependency graph of any prior node. But that would mean
>that all dependency graphs need to be always chased for every
>node, that's kind of mind-boggling.
It is, which is why people are trying to apply keys to approach the
problem: keys are the usual XSLT device for creating associations between
elements based on relationships other than the structures they come in (in
your case, cross-references between the elements). The fact that a given
key value can return several matching nodes is an important feature,
allowing for grouping (which idiom has made Steve Muench immortal) -- which
may be exactly what you really need -- and other kinds of operations that
defy the logic of document order.
I think a key approach would do it for you; if even that comes up short,
the next strategy to consider would be to break your processing into two
passes. XSLT gets really powerful when you use a stylesheet to generate
either a new source file optimized for the next pass, or a second
stylesheet to run over the same source.
Does that suggest directions for you to think in?
Cheers,
Wendell
======================================================================
Wendell Piez mailto:wapiez@mulberrytech.com
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
======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list