[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] Easy question, big headache.


Subject: RE: [xsl] Easy question, big headache.
From: "Patrick Bergeron" <pbergeron@xxxxxxxxxxx>
Date: Tue, 11 Mar 2008 15:03:25 -0400

First, thanks all for the numerous responses even if there doesn't seem to
be a silver bullet. 

It's true, the initial post was a gross simplification - that was actually
very deliberate. I didn't want to start a discussion where I'd have to
explain convoluted rules, and I just wanted to see if someone could propose
a solution that didn't involve copying the whole tree and do the marker
insertion in yet another pass.   I had left the question open in case
someone could post an easy solution which, GASP!, would have found a
creative way to create and update a variable (or even a node element!), but
I guess that's just not going to happen.


I don't think the code is too monolithic -- at the core it does
template-matches on the nodes of a tree that has been time-sorted in a first
pass, and then maybe outputs a corresponding record. Then if "a special
case" occurs, treat those individually by using previous records in the
tree, including those that may have not been output directly.

And yes, XSLT 1.0 is a constraint I need to live with, too bad.



-----Original Message-----
From: Michael Kay [mailto:mike@xxxxxxxxxxxx] 
Sent: Tuesday, March 11, 2008 12:35 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] Easy question, big headache.

 
> And I need to output some of these records, but not all of 
> them. The rules upon which I decide to output are complex, 
> and I won't bore you with the details.
> 
> Also, after every 5th record has been output, I need to write 
> some kind of marker in the output stream.

The discussion has been interesting. It sounds from your later description
as if the first paragraph above was a gross simplification: that is, the
output records don't correspond one-to-one with a subset of the input
records, which means that the first technique I suggested isn't applicable.

In this situation I would lean strongly towards a two-pass approach. It's
interesting that your code appears already to be suffering from being too
complex and monolithic; a multi-pass approach is the best way of avoiding
this creeping complexity, and you certainly don't want it to get any worse.

Your concern about the two-pass approach seems primarily to be memory usage.
This is a technology issue rather than a language issue. The fact that you
are using XSLT 1.0 presumably means you are constrained in your choice of
technology - I don't recall seeing you say what these constraints are. With
XSLT 2.0 there is a much better chance, I think, that the second phase
(interpolating the marker elements) could be done in pure streaming mode
with no additional memory requirements. It might also allow a substantial
simplification (and speed-up) of your existing code.

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


Current Thread
Keywords