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

Re: Non-XML XSL output

---

---

"Simon St.Laurent" wrote:
> 
> At 04:16 PM 2/27/99 -0500, Jonathan Borden wrote:

> >       It is conceivable that a use of result-ns might be a signal to an XSL
> >processor than the FOT be subsequently processed into a particular non-XML
> >format after the initial transformation.

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.

> All of this is great, and highly useful, but in the context of 'full' XSL,
> and not just the tree-construction part.  What I find difficult to accept
> is that a tool which purports only to handle the transformation end is
> outputting stuff that ain't XML, especially given the context of the
> discussions on this list and section 2.5, based on a namespace.

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?

> If I started outputting troff files directly without concern for formatting
> objects, I think there'd be a sudden round of griping.

If it was triggered by use of the result-ns attribute, there would be no
cause for griping.  Take TeXML for example.  If that has a result
namespace associated with it, then a browser could be configurable so
that when a document with that namespace was encountered, it ran the
TeXML to TeX filter, ran TeX and an appropriate driver and displayed the
result in the browser.

> It seems as if we're sticking back-end processors on XSL here that have
> behaviors not defined by the specification but without acknowledging that
> fact.  Supporting old-style SGML-valid HTML is pretty much a waste of time
> in my book

I don't agree. There are lots of little gotchas with this XML in HTML
approach. For example, you have to play all sorts of silly games to get
SCRIPT to work.  And with old browsers this simply doesn't work.  For
example, with some browsers you have to use <dl compact> rather than <dl
compact=compact>.  Eventually everybody will support XHTML, and support
for HTML 4.0 won't be necessary, but I think that is several years away.

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

James


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

---