Subject: RE: [xsl] optimization for very large, flat documents From: "Pawson, David" <David.Pawson@xxxxxxxxxxx> Date: Wed, 19 Jan 2005 09:59:41 -0000 |
-----Original Message----- From: Michael Kay > Why doesn't XSLT provide a way to specify that a matched node can be > processed independently of its predecessor and successor siblings? > siblings? I think the reason that XSLT vendors have not tried this approach is: (b) for such stylesheets, a completely different run-time approach is needed: effectively, a different XSLT processor. I think that in practice if you want to do serial transformation then a functional language is not the right answer: if you can only look at each piece of input data once, then you need the ability to remember what you have seen, so you need a procedural language with updatable memory. That's why STX was invented. However, I think there is scope for someone to package up the idea of running an XSLT transform on each "record" in a large file, and then recombining the results. With the number of times this issue comes up Mike, I'm surprised the WG haven't considered it, or some variant such as the STX approach? I.e. some means of XSLT-like processing for large document, even given a strict list of restrictions. It would appear that (most of) the constraints are known; The use case should (or could be) readily determined; All that's missing is the impetus to move on this. Perhaps once the smoke has cleared from xslt 2.0? regards DaveP -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] optimization for very lar, Pieter Reint Siegers | Thread | RE: [xsl] optimization for very lar, Michael Kay |
[xsl] XPath performance comparisons, Michael Kay | Date | Re: [xsl] XPath performance compari, Dimitre Novatchev |
Month |