Re: result-ns (was RE: XSLT vs JSP)

Subject: Re: result-ns (was RE: XSLT vs JSP)
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Mon, 28 Jun 1999 17:11:23 +0200
Simon St.Laurent <simonstl@xxxxxxxxxxxx> wrote:
>Yikes.  I still can't understand why anyone considers result-ns a good way
>to indicate what the result syntax should be,

This is a way to work around XML syntax limitations without having to extend
XSLT in any way. For example, it allows an XSLT processor to support CDATA
output elements such as SCRIPT for HTML, even though they are illegal in
XML. If/when a new output syntax comes along which is vaguely hierarchical,
this mechanism would allow supporting it by specifying the appropriate
namespace - without any change at all to the XSLT specs.

The alternative would have been to extend XSLT to explicitly support non-XML
constructs (such as CDATA), which some people feel very strongly about.
Using namespaces is a very elegant way to avoid this problem - even though
it is a hack.

Another point is that you would give up on ensuring the validity of the
structure of the resulting document. This already happens when, for example,
generating embedded JavaScript code in HTML documents - there's no way to be
certain that each '{' has a matching '}'. I've been bitten by that quite a
bit, actually. If I was able to specify <js:block>...</js:block>,
<js:string>...</js:string> (which would have handled quoting for me) etc.,
then generating such code would have been easier. Of course, how to mix
several output namespaces is not exactly clear at the moment...

>leaving it up to every XSL
>processor to keep a list of namespaces and provide code for supporting

That's the down side of this hack. The spec defines very few standard
namespaces, which means that generating XML or HTML is OK and anything else
is processor dependent. James Clark has implemented in XT a namespace for
generating arbitrary output text. I'd really like to see it (or something
like it) make its way to the specs, since it is a very useful "safety
valve" - with some effort one can generate anything at all using it.

>Maybe if there was a pluggable module for handling result-ns, or, better, a
>vocabulary developers could use to describe to the result syntax that was
>somehow referenced by the XSL style sheet, this approach could work
>smoothly.  Right now it feels like a random bit hanging off the side of the
>spec.  Maybe it's just an escape clause, but I can't say it feels like a
>'real' solution - that's probably why it's described as a 'hint' in Section

What you describe already exists :-) Simply emit the document in standard
XML syntax, then feed it into another XSLT pass, using a stylesheet
describing the output syntax, and whose output is in James Clark's
any-possible-text namespace. Problem solved.

If there was an easy/standard way to specify that an XML document has to go
through a _chain_ of stylesheets, the above would become trivial and
probably be the recommended way to add new syntax forms (instead of adding
magical namespaces). By providing a stylesheet one would know the new syntax
would work with any XSLT processor. That's why something James Clark's
any-possible-text namespace should be part of the specs.

There are other advantages to this approach. For example, it would remove
the need to be able to match on result tree fragments. Instead processing
would be broken to explicit stages. If each stage is "incremental", then the
chain would also be. Debugging such a chain would be easier then debugging a
monolithing stylesheet. Another bonus is the ability to develop reusable
XSLT components.

Have fun,

    Oren Ben-Kiki

 XSL-List info and archive:

Current Thread