RE: Streaming XSL

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

Hi Oren,

[... your comment on streams....]

<Reply>
I am listening carefully the actual discussion about streams on xml-dev
because I am working on this. This issues I encountered so far:

- priority (to resolve priority between rule/template we need the whole
grove... hoops the whole DOM).
- rule/template dependencies.

I agree with you that what we need is a something that says that this
rule/template is not dependent on any other rule and that it can be fired as
soon as a begin-markup...end-markup structure is encountered.

I don't want to enter in the same Byzantines discussions as in xml-dev but
I'll explain what we do from a practical point of view.

In a stream, as soon as the first PI giving the xml version and encoding is
encountered, then the appropriate parser can be selected (in case we have
more than one version). We have created the notion of a stream handler for
this. The stream handler waits on the stream for a xml PI or a sgml
declaration. When the PI is encountered, the right parser is then ready to
receive the input.

After the xml PI and the xml parser is loaded and initialized, then the
stream handler wait for the style PI or an other PI that indicates what kind
of interpretation we do on a XML document. Thus, the syntax router needs two
PI

- the first to indicate how to decode the stream
- the second to know to interpret the stream

If the xml-stylesheet PI is encountered then the style interpreter is
loaded. The stream hanlder has both condition fulfilled: a) how to decode
the stream with the appropriate syntax handler (i.e. parser), what to do
with the parsing result (i.e. associate the parser with the right
interpreter). If the second PI is a xml-stylesheet PI then the stream is
interpreted by a XSL/DSSSL/CSSS interpreter (in fact, one of these because
they are not the same software). We also use an other kind of PI to
associate the stream to a different knid of interpreter ( a sotck
interpreter)

Because there is no attribute in XSL to indicate that each rule/template is
autonomous we relied on the PI so that we didn't changed the XSL syntax -
same thing for dsssl. We created a new media property for this the "stream"
media property. So if the xml document has a PI like:
<?xml-stylesheet href="myscript.xsl" type="text/xsl" media="stream"?>
then we process each template/rule independently as soon as a complete
markup is arrived. This impose that we cannot query for a property or
element located outside this markup and its children. If this is the case,
an error is generated. So each template has to be a complete expression
without any external dependencies, except with markup children dependencies.

For most of the streams, it seems to work
the pros:
each template is very modular and this facilitate re-use

the cons:
we can not build more sophisticated style sheets.


We discovered however that the PI mechanism could be extended to other
things like for instance an interpreter that stores stocks data in a
database. We created a PI for this: <?xml-interpreter href="myapp.exe"
type="application/test-stock" media="stream"?>

I know that the media was more intended for the output than for the input
and we are using it temporarily, until we find a good solution.

So, I wont argue if this is a document, a horse, a turtle or a frog but this
is how we process stream based xml or sgml formats.

<algorithm>
a) first PI used to set the format
b) second PI used to set the interpreter that will do something with this
format.
</algorithm>

A new IETF chapter called MEMUX is now created, we intend to test the
concept on MEMUX. You can get more info on MEMUX at:
http://www.w3.org/Protocols/HTTP-NG/1999/02/mux-Charter-222.html
</Reply>

Regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list