RE: Streaming XSL

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

HI Oren,

<YourComment>
The use of a "stream" media to specify this seems like a kludge (though I
appreciate how you came to use it in the current framework). It really
should be in the <xsl:stylesheet> element.
</YourComment>

<Reply>
I agree 100%. Actually, if we look closely to XSL specs or to any other xml
processing stuff. We have no common way to associate an interpreter to a XML
document. A XML document without an associated interpreter is nothing more
than just sleeping data in a serialized format. What we should have:

a) a way to set interpreter properties like we can do with command line
properties. This is how we use and interpret processing instructions. In a
XML stream, we consider processing instruction as what the term say it is: a
processing instruction. We can tell to an interpreter waht are the
parameters given to it for processing.
b) We should also be able to specify constrain within the language and not
solely to the processor. The <xsl:stylesheet> element seems indeed to bve a
good candidate for this.

But, I guess we will see that feature more in version 2 or 3 if we see it.
Until then, we will have to rely on processing instruction and consider that
a processing instruction is like giving parameters to an interpreter like
(as an analogy) we do with system command lines. This feature could
compensate for a version 1.0 (or I should say 0.9) limitations.

My own proposal would be for a <?xml-interpreter....?> processing
instruction which can generalize the notion of XML format interpretation.
The actual xml-stylesheet is ok but restricted to style sheet. The former PI
could be used for any kind of interpreter. The properties added to this PI
could depend on the interpreter like we have different command line
parameter for different tools. Thus, the parameter set could be expandable
and different from an interpreter to an other. Again, the trick here is to
consider the PI like a command line.
</Reply>

<YourCommand>
BTW, is there a simple syntactic restriction associated with "stream"
stylesheets, so that the XSL processor could immediately report an invalid
sheet? Things like never use absolute element path in select patterns, never
select siblings, that sort of thing?
</YourComment>

<Reply>
Yes your suggestion is useful. What would be useful is a way to set these
constrainst. Oren, do you have a suggestion? (I am sure you have one ;-).
Because we cannot change XSL version 0.9 (too late now if we still target
August) we can then use the xml-interpreter PI instead. We have more freedom
with this PI and W3C can see that as a lab experiment :-) I hope we won't
get burned on the public place by creating a new entity :-) At least it is
to correct current limitations. Do you think I should bring this thread to
xml-dev?
</Reply>

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


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