RE: optimization for very large, flat documents

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