Fw: Streaming XSL

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

Didier PH Martin <martind@xxxxxxxxxxxxx> wrote:

I wrote:
Actually I'm not thrilled with this "associate-a-program-with-each-file"
paradigm, however popular it became in windowing systems. The same file
might be processable by several unrelated interpreters. At any rate, this
seems something outside the scope of XML.

>But you have to do it in some way though. Either with a command line type
>stuff or anything else. But remember, we where taking about streams and
ways
>to tell the other end of the stream what to do.

Whoa! I never said any such thing. Let's keep two issues separate:

- Defining XSL so that an XSL processor wouldn't necessarily have to read
the whole input document into memory. This would make XSL usable for large
documents and, yes, for handling streams (if there is such a thing :-).

- Handling arbitrary (XML?) streams in a complex system - redirecting parts
of the stream to appropriate XML handlers, passing them through the right
filters, and so on.

The two questions aren't related except that if the first isn't resolved,
XSL wouldn't be very usable in a system built along the lines of the second.

"All" I suggested was the simplest possible mechanism (I hope) to allow XSL
to handle arbitrary-sized input documents. There was/is a thread discussing
XSL CPU complexity - I think that worrying about memory consumption is as
important.

I'm well aware of the discussion in xml-dev of how to handle XML streams,
and while I have my own opinions on the matter :-) I think this is
by-and-large irrelevant to XSL, except for the first point above. Not that
the second question isn't interesting - it is, very - but it is a very
different one.

>Pocessing instruction is a
>clean way to do it.

Agreed. You could, for example, have your "stream" be constructed as:

<?my-stream-processor how-to-handle-next-xml-doc?>
an XML document...
<?my-stream-processor how-to-handle-next-xml-doc?>
an XML document...

That would be a valid use of PIs, IMHO.

As for how to name such PIs, I suggested it could be anything the XML
processor would like. You've said:

>Or we can get a single <?xml-something...?> for a very simple pattern
match.

Well, the only benefit would be that if it is agreed that <?xml-pragma
for="URI"?> has a required 'for' attribute which is a URI, then we solve the
namespace problem. You have suggested using mime types. Hmmmm... I think
this issue has probably popped up in other places - someone should define a
standard URI for mime types, as in "mime:text/xsl" so that both would be
supported. It should be the W3C, I presume, but which WG?

At any rate, using <?interpreter-name ...?> has one great advantage - it
would work today, without any changes to any standard, spec, or program.
Kind of hard to beat. I doubt whether name space issues would really be a
problem here - after all, such PIs indicate one knows which interpreter is
about to process the document.

>Do you think I should bring this thread to
>xml-dev?


Well, the idea of <?xml-pragma for="URI" ...?> belongs there. Also PI
approach to punctuating streams (as opposed to ^L or whatever). But neither
one has much to do with my original purpose - makeing XSL memory-efficient
for processing large documents (and streams).

>So, instead
>of <?xml-stylesheet..?> we would have <?xsl...?> etc... Is that what you
>mean?

<xsl:stylesheet> is an element, not a PI, and should stay that way. I
thought of two specific PIs:

<?xsl default-templates-are="complete?>

And

<?xsl next-template-is="complete"?>

Which XSL processor implementers could then use to create more efficient XSL
processors. Of course, assuming we can't just add the 'complete' attribute
directly to <xsl:stylsheet> and <xsl:template>.

>if yes, it is easy to implement and should please to the New Jersey
>people :-) and the pragmatic ones like me. And it has the benefit to be
>general and open the doors to myriad of xml interpreters. The problem with
>this schema now is a problem of registration. MIME type is more standard.
So
>what about:
><?xml-interpreter type="yourtypehere"......everything else is interpreter
>dependant a considered as a parameter list for this interpreter...?>
>MIME type property is used to select the right interpreter and is therefore
>mandatory. Thus only the PI indentifier xml-interpreter and the type
>property would be mandatory everything else optional and intepreter
>dependant. All properties would be treated as interpreter parameters. what
>do you think?

I'd rather call it <?xml-pragma?> and use for="URI", but I agree that would
be a worthwhile addition to the XML standard. The point is you can start
using <?vim ...?> today, and in order to use <?xml-pragma
for="http://www.vim.org"; ...?> we'd have to wait about a year for some WG to
formalize it. BTW, this "vim" example shows why a mime type won't do. A URI
is more general.

Have fun,

    Oren Ben-Kiki


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