This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: MS chat tidbits
- To: xsl-list at mulberrytech dot com
- Subject: Re: MS chat tidbits
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Fri, 09 Jun 2000 01:45:39 -0700
- Organization: The Qub Group
- References: <Pine.LNX.4.21.0006090911570.32525-100000@ted.sergeant.org>
- Reply-To: xsl-list at mulberrytech dot com
> On Thu, 8 Jun 2000, Jon Smirl wrote:
>
> > We better not see a patent on this, I've been using streamed SAX XSL
> > processing with XT for over a year now. This has been a feature of XT since
> > the day it was released. XSL has never had a requirement that the input or
> > output of the processor be actual trees only abstract ones. There is also
> > prior art on compiling an XSL sheet where a schema describes the input and
> > using the schema to improve the compilation.
>
> IIRC, XT simply uses the SAX stream to create it's own internal tree
> structure. It's not a streaming XSLT implementation.
I think both views are consistent with MS ... messy ... 'technical' ...
info...
XT is streaming in a sense that XSLProcessorImpl is actually
SAXParser ;-)
<cut>
import org.xml.sax.Parser;
public interface XSLProcessor extends Parser {
}
public class XSLProcessorImpl implements XSLProcessor, Cloneable, ParameterSet {
</cut>
Does it mean XT is 'streaming' ? Yes. SAXParser is 'streaming'
by definition.
Has it memory footprint? Yes, because this 'SAXParser' is very
special, it loads the entire document into memory.
Is MS talking about *this* memory footprint or about some other memory
footprint ?
No way to answer.
We can only guess what do they mean, because having XSLT engine in form of
SAXParser already saves some memory. Not "that much", but ...
Rgds.Paul.
PS. Streaming XSLT is doable, but it is hardly 'one man project'.
It is 2-man-year project. But weekends are too short.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list