Re: GOTCHA!

[Tyler Baker <tyler@xxxxxxxxxxx>]

Oren Ben-Kiki wrote:

> >Sorry to spoil the party.
>
> Not quite. If someone wants to generate non-XML output - be it TeX, RTF,
> JavaScript, C++, PDF, PostScript, or whatever - then the following rule:
>
> <xsl:template match="/">
> <xsl:comment>
> <xsl:apply-templates/>
> </xsl:comment>
> </xsl:template>
>
> Will ensure that he's able to generate _almost_ any output language he
> wants. This technique solves some of the problems people have been
> complaining about in this list, and is perfectly legal XSL. This should be
> in the FAQ (if we had one).

Really?  I thought that comment elements and pi elements as well as attribute
elements cannot have markup as output.  My understanding here is that an XSL
Processor may flag an error if you say have an xsl:element as a descendant of an
xsl:comment element.

> Is there a chance to add an <xsl:not-xml>...</xsl:not-xml> tag which would
> work just like <xsl:comment> but will not emit any start-of-comment and
> end-of-comment strings, and will allow anything in the output? It is outside
> the intent, granted, but is sooooo useful in practice... Think of it as a
> safety valve on a pressure cooker :-) Also, by tracking the use people make
> of it in real world applications, you could get a pretty good feel for which
> areas of the standard need attension in version 2.0.

This is where non-standard proprietarty extensions are in order.  In this sense,
just think of writing the result tree to a DOM Document (LotusXSL I think does
this) and then have some routine which spits out the DOM document to anything
you want.  Most XSL Processors.  Just think of XSL as a transformation language
for doing XML to XML and then everything after that is post processing (though
actual XSL Processor implementations may have native result interfaces).  You
could have your own literal result element which is used as a wrapper for
emitting non-XML output.

> Here's another point which presumably is well inside the intent. The current
> formatting objects are only capable of specifying a static document. In this
> day and age this is hardly sufficient. HTML has solved the problem by
> allowing embedded JavaScript code, and presumably the 'fo:' namespace will
> have to do so as well  (this has nothing to do with embedding scripting
> inside the XSL stylesheet itself).
>
> Now, JavaScript has very different quoting rules then XML. For example,
> inside strings, " and \ must be prefixed by another \, \u1234 is the way to
> specify unicode characters, etc. If an XSL processor was expected to
> generate the JavaScript code embedded in a hypothetical 'fo:script' tag, it
> wouldn't be able to do so unless it was extended in some manner.
>
> The "right" way would be to define another namespace - <js:*> perhaps -
> which would generate valid JavaScript (e.g., <js:function>,
> <js:literal-array>). This is a large task, and is not being even considered
> at the moment as far as I know. A shorter way would be to provide
> <xsl:ecma-script-code> and <xsl:ecma-script-string> tags and give up on the
> restriction that the output would always be syntactically correct
> JavaScript.
>
> Note that both these approaches share one tag -
> <js:string>/<xsl:ecma-script-string>. The lack of this tag makes it
> impossible to generate embedded JavaScript from XSL processors today. Could
> we "jump the gun" with this single tag? It falls under the intent (well, a
> future version of it, anyway), is simple to implement, and is useful right
> now. How about it?

This would be a trivial extension in a late-binding language like Java, but in a
language like C this is a bit more difficult to support.  The more I see XSL in
real-world use, it seems like virtually everyone doing stuff with XSL is doing
it in Java.  Perhaps, the XSL spec could be loosened up to have optional Java
specific extension support.  After all some people may prefer PERL to JavaScript
at least on the server side of things.

Tyler


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