[
Lists Home |
Date Index |
Thread Index
]
- From: Clark Evans <clark.evans@manhattanproject.com>
- To: Paul Prescod <paul@prescod.net>
- Date: Thu, 04 Feb 1999 19:06:58 +0000
Paul Prescod wrote:
> Peter Seibel wrote:
> > >> Is there a possibility for creating a sub-set of
> > >> XSL that would work on a stream instead of
> > >> requiring a complete document object?
> > >Funny you should ask that, I've been experimenting over the last few days to
> > >see whether I could build such a thing on top of SAXON. Not actually easy to
> > >do as a pure subset, but I think one can do something that feels quite
> > >XSL-like.
> > So I obviously lack imagination or understanding of all the intricacies of
> > XSL -- what can you express in XSL that you couldn't implement on top of SAX?
>
> How do I build a table of contents that is output BEFORE the document
> without reading the whole input before I start to output?
>
Exactly :) With a weak-XSL you coudn't build the table of
contents BEFORE the entire stream is read, the same with
sorting, you can't do it before the entire stream is read.
However, it can do other things, like turning a <catalog>
into a <table>, building a index or trailing table of
contents, etc. Thus it still has use for translating
XML into HTML and other output forms, while not requiring
the memory and processing overhead.
Also, if you really needed the stream sorted or a table
of contents first, there is nothing preventing the producer
of the stream (a database?) from doing this.
Don Park wrote:
>
> The DOM spec does NOT require the entire stream to be read before the
> document object is returned. Some of the DOM implementations available
> today does indeed process the entire stream before returning but that is a
> quality of implementation issue.
Really?
DOM specification:
>
> interface Node {
> readonly attribute NodeList childNodes;
> readonly attribute Node lastChild;
> };
>
> interface NodeList {
> Node item(in unsigned long index);
> readonly attribute unsigned long length;
> };
It seems that these two in combination would make a
recursion that would require the entire stream to
be read before the object would be useable.
I guess you _could_ make these attributes smart
methods that would BLOCK if the information
required to satisfy the request was not yet
available. But then, anyone using the DOM
would have to use these attributes understanding
that any one of them may block for a minute
or more while the stream "catches up"...
I'm not sure that this is valueable, especially
when SAX provides such a nice stream-oriented
interface to XML documents.
:) Clark
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|