xsl-list
[Top] [All Lists]

RE: optimization for very large, flat documents

2005-01-19 02:59:41
 

    -----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




--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--