A weaker XSL?

[Clark Evans]

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 at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)