Subject: Re: GOTCHA!
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Wed, 13 Jan 1999 14:23:13 +0200
Tyler Baker <tyler@xxxxxxxxxxx> wrote:

>Oren Ben-Kiki wrote:
>> 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
>> in the FAQ (if we had one).
>Really?  I thought that comment elements and pi elements as well as
>elements cannot have markup as output.  My understanding here is that an
>Processor may flag an error if you say have an xsl:element as a descendant
of an
>xsl:comment element.

Who wants to write <xsl:element> inside a JavaScript code? As long as
<xsl:text> works I'm happy.

>> Is there a chance to add an <xsl:not-xml>...</xsl:not-xml> tag which
>> 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
>> 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
>> of it in real world applications, you could get a pretty good feel for
>> areas of the standard need attension in version 2.0.
>This is where non-standard proprietarty extensions are in order.  In this
>just think of writing the result tree to a DOM Document (LotusXSL I think
>this) and then have some routine which spits out the DOM document to
>you want.  Most XSL Processors.  Just think of XSL as a transformation
>for doing XML to XML and then everything after that is post processing
>actual XSL Processor implementations may have native result interfaces).
>could have your own literal result element which is used as a wrapper for
>emitting non-XML output.

This is fine as long as I can pick and choose my XSL processor. My
application will need to deal with whatever XSL processor available at the
client's machine, which removes the possibility for such tricks (unless the
hooks for them are made standard, and there isn't much chance for that).

>> ... 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.
>> we "jump the gun" with this single tag? It falls under the intent (well,
>> future version of it, anyway), is simple to implement, and is useful
>> 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
>it in Java.  Perhaps, the XSL spec could be loosened up to have optional
>specific extension support.  After all some people may prefer PERL to
>at least on the server side of things.

This is difficult to implement if you are thinking of something like XT's
<xsl:filter> element, perhaps. I was thinking of a hardwired
<xsl:ecma-script-string> element whose behavior is fixed (by the ECMA
standard) - so there's no problem using any language.

Share & Enjoy,

    Oren Ben-Kiki

 XSL-List info and archive:

Current Thread