[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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Easy question, big headac, Michael Kay | Thread | Re: [xsl] Easy question, big headac, Colin Adams |
RE: [xsl] Processing on both a docu, Bjorndahl, Brad | Date | RE: [xsl] Manipulating elements dep, Michael Kay |
Month |
Keywords