[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Fw: Streaming XSL


Subject: Fw: Streaming XSL
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Tue, 23 Feb 1999 20:54:55 +0200

Didier PH Martin <martind@xxxxxxxxxxxxx> wrote:
>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:


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.

>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.

Isn't there some rule which says that unrecognized processing instructions
are ignored? It is then quite OK to have processing instructions specific
for a certain interpreter, or even for several unrelated ones, without
harming processing by other XML tools.

This would be similar to the way that some text editors recognize lines in
certain formats in order to customize the handling of text files - choosing
the right syntax highlighting or whatever - without harming the semantics of
the file itself.

>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.

Is it _really_ too late to discuss things like the 'complete' attribute for
<xsl:template> or <xsl:stylesheet>? (Hopefully) August is still a long time
in the future...

>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.


I'd rather have:

<?vim vim customization?>
<?emacs emacs customization?>

Etc. - that is, let each interpreter recognize a set of PIs if it wants to,
and ignore the rest. Not that you can stop them from going that way, anyway,
since it is standard XML. But I think that encouregment - and some mechanism
for registering the PIs somewhere so they won't collide and would converge
to common forms - is something the W3C should consider.

In our case, consider:

<?my-xsl-processor by-default-templates-are="[in]complete"?>

Which should appear _before_ <xsl:stylesheet>, and:

<?my-xsl-processor next-template-is="[in]complete"?>

Which should appear before the effected <xsl:template>.

If I understood you correctly, you could trivially modify your processor to
recognize some form of the first PI above, instead of relying on the 'media'
hack. If anyone decides to implement a more complete solution, he could rely
on something like the second PI.

This is OK as long as the PIs do not effect the semantics of the XSL
transformation - that is, as long as they are just "optimization hints".
This is true for the above two PIs.

Anyway, this is still second best. I'd still rather that the XSL proposal
would directly address the issue of processing large documents. How about a
compromise:

Include in the XSL proposal a list of recommended PIs using the reserved
<?xsl-processor ...?> name - the above two being in this list, of course :-)
Implementers would then choose which, if any, of these PIs to implement, and
may add their own. When version 2 comes in, we'd be able to track which of
these PIs are used in practice, which new ones were added etc. and integrate
the functionality into XSL itself (if it makes sense to).

This was done in HTTP, for example - there is a 'pragma' header field, a
recommended value of 'no-cache' was defined in HTTP/1.0 and widely
implemented, and as a result of the experience gained using it a special
'cache-control' field was added in HTTP/1.1.

>I hope we won't
>get burned on the public place by creating a new entity :-)

There's no new entity involved, just using the existing PI mechanism.

>At least it is
>to correct current limitations.

Which is exactly what 'pragma's are all about :-)

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


No need. The mechanism is already there, in standard XML, today.

Share & Enjoy,

    Oren Ben-Kiki


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



Current Thread
Keywords