Re: Non-XML XSL output

Subject: Re: Non-XML XSL output
From: "Simon St.Laurent" <simonstl@xxxxxxxxxxxx>
Date: Sun, 28 Feb 1999 09:17:25 -0500
At 10:03 AM 2/28/99 +0700, James Clark wrote:
>Exactly.  When you use specify the result-ns attribute, you are saying
>to the XSL processor: this XML tree has semantics associated with;
>process this tree so as to give effect to those semantics.
>
>The result of the tree construction part is a tree, not a sequence of
>characters or bytes.  The spec does not require this tree to be
>converted to a sequence of characters or bytes.  Why not? Because that
>would be useless overhead in the 'full' XSL case.  So what's the right
>thing for a tool implementing the tree construction part to do?  It
>should provide access to the result tree using a standard interface (in
>the case of XT this is SAX), and should provide access to the result-ns
>attribute if specified, and should allow different processing to be
>associated with different namespaces specified with the result-ns
>attribute; this allows you to plug in an implementation of the FO part
>and get a full XSL implementation.  That's exactly what XT does.  The
>com.jclark.xsl.sax.Driver class exercises this by associating the HTML
>4.0 namespace with a SAX DocumentHandler that writes the XML tree out as
>an HTML 4.0 document.  Note that this processing isn't triggered merely
>by the result tree's using the namespace.  It is only triggered when you
>also use the result-ns attribute to indicate that you want special
>processing of the result tree. 
>
>If you want the result tree written out as XML, don't specify the
>result-ns attribute. What is difficult to accept about that?

Well, it's not really that difficult, except that the result-ns material
gets about half a page, in a note, and it's not really clear from the spec
how that result-ns material fits in with the general framework of XSL.
Again, splitting off tree construction from formatting objects and
providing a clearer description of the output the tree construction end can
produce (whether it's XML, HTML, SGML, troff, TeX, or something entirely
different) would make this much much clearer and might resolve a lot of
general questions about XSL.

This processing is intriguing, if grossly underspecified - the result-ns is
only a tidbit of information, and I can see 50 different processors
producing 50 slightly different interpretations of a tree based on that
namespaces and their implementation of it.  Perhaps an interesting project
(though one outside the present scope of XSL) would be to develop a generic
framework for describing how the tree should be re-serialized.

In any event, no matter how it happens, it seems like we may have an answer
to Paul Prescod's concerns about SVG and its use of the style attribute.
As long as we're willing to accomodate issues like:

>For
>example, with some browsers you have to use <dl compact> rather than <dl
>compact=compact>. 

It seems pretty simple to convert a tree representation of style
properties, say

rect 
	css:fill="red" 
	css:fill-opacity="20%"

into:

<rect style="fill: red; fill-opacity:20%;"/>

instead of just

<rect css:fill="red" css:fill-opacity="20%"/>

It also seems like it might be reasonable to support this for other
formats, including HTML.  Unfortunately, it doesn't seem likely result-ns
of http://www.w3.org/TR/REC-html40 doesn't provide any support for these
kinds of output, as far as I can tell.  A processor fed a result-ns value
of http://www.w3.org/TR/WD-SVG might know to do it, but we have no way of
telling it to do it or knowing whether it could do it.

It seems like we're back to the model of 'pick an implementation that
supports your particular framework' instead of the model of 'XSL is a
standard, and all implementations should export the same output given an
identical set of input.'  Maybe that's acceptable.

>> If we're going to operate this way, it's fine with me - just drop all the
>> "we're only generating XML" rhetoric
>
>It's not rhetoric.  We are only generating XML trees.  We also provide a
>way of triggering processing of that tree.  That's the minimum that's
>needed to support 'full' XSL.

It's only rhetoric when folks claim that the fact that XSL generates XML
trees privileges a particular kind of output and that other standards
should conform to that output rather than XSL demonstrating some
flexibility to accomodate other standards.  It seems like we're now going
the route of more flexibility, albeit in a way that comes with little
control over the flexibility.

Simon St.Laurent
XML: A Primer / Building XML Applications (April)
Sharing Bandwidth / Cookies
http://www.simonstl.com


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


Current Thread