[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: GOTCHA!
G. Ken Holman <gkholman@xxxxxxxxxxxxxxxxxxxx> wrote: >At 99/01/12 20:29 +0200, Oren Ben-Kiki wrote: >>Suppose you have a rule which goes: >> >><xsl:template match="..."> >><xsl:comment> --> >>Whatever I damn please, including <, &!!! >><!-- </xsl:comment> >></xsl:template> >> >>Running this through XT will emit: >> >><!-- --> >>Whatever I damn please, including <, &!!! >><!-- --> > >Section 2.7.5 reads (in part): > >========8<------- >It is an error if if the result of instantiating the content of the >xsl:comment contains the string -- or ends with -. An XSL processor may >signal the error; if it does not signal the error, it must recover by >inserting a space after any occurrence of - that is followed by another -. >========8<------- > >So, when repaired, XT could not be relied upon to give the above behaviour. Oh, I knew it is a bug... And James indicated it is a known one, so it won't last. I'm still interested to know which processors share it. >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). 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. 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? Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|