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 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. 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 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. 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. 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. 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: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: GOTCHA!, James Clark | Thread | Re: GOTCHA!, Oren Ben-Kiki |
Re: GOTCHA!, Oren Ben-Kiki | Date | Re: GOTCHA!, Oren Ben-Kiki |
Month |