[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSL template "namespace" problem
Hi Ian,
At 08:29 PM 3/29/2006, you wrote: Actually as we pointed out your second example (the one I modified with xsl:text) was well-formed XSLT all along. It was the goofy Right. "Well-formed" describes a property of the format's syntax (either it's good to go for an XML parser or it isn't). In properly-designed XML systems the higher-order "semantics" are bound typically to element and attribute names and values, and are not driven by syntactic constructs. (This layering is the key to the portability of XML applications across toolkits.) The presence or absence of Javascript in either the XSLT or the HTML result has *no bearing* on whether the file is well-formed or not. To an XML parser the Javascript is just text, like any other. The rules of well-formedness dictate how XML tags are constructed and how they are applied to text data; apart from restricting the data content not to have unescaped "<" and "&" characters (since those say "markup starts here!"), these rules do not limit what you put in that text, whether it be Javascript or anything else. It depends on what you mean by "work". It will *never* work in the sense of "be intepreted and do something as Javascript". In the XSLT and until the result is created, it's just more string data. Once it gets passed up to the HTML layer, however, it might then work. In principle this should have nothing to do with how it was handled in the transformation, where it was treated just like any other string. I mean, as I saw earlier, "&&" in a <SCRIPT> tag totally screws up XSLT processing, since its not a "well-formed" identifier. I realized you have to enclose it in a <![CDATA[]]> tag, or in an <xsl:text> tag. Yes. This is the level of detail that goes to show the difference here. The reason "&&" blows up has nothing to do with the correctness of the Javascript. It's simply and only that the "&" character is reserved (for entity and character references), so if you want to have that character in your text data (note again: not "in your Javascript", but in your text data altogether) you must escape it, as "& amp;" (I drop a space in there to confound over-eager mailers). Accordingly the way to write one && two in XML is one && two The problem is that many Javascript interpreters won't recognize that as "&&". This is why when writing HTML, XSLT serializers have a special instruction not to escape "&" when writing out HTML <script> elements. If you're writing out XML syntax, however, this won't work for you ... since XML syntax requires the output to follow the well-formedness rules, and a literal "&&" requires you to break them. The use of CDATA marked sections steps in as the next-best workaround. <xsl:text> by itself won't work for you, although if you use the optional "disable-output-escaping" feature you can sometimes get an XSLT 1.0 processor (or rather, its serializer) to leave your "&" alone. Of course, this does mean you're explicitly opting *not* to have your output conform to XML rules. Sometimes people feel this is an acceptable price to pay for ecumenism in the browser. Personally I'd rather find a clean way to do it ... and maintaining your Javascript in an external file is exactly such a way (then the code never has to be picked up and possibly mangled by an XML parser). This is a good thing to do because it controls the various layers more discretely; but if you're doing it without understanding why, you're only solving your problem until the next time you have it. Understanding what "well-formedness" consists of (and doesn't) in the context of XML is pretty basic. That all makes good sense. CSS stylesheets are applied to HTML documents by the rendering engine, which does its work independently of any XML transformation. (More usually, the browser is simply delivered HTML and perhaps CSS, and the rendering engine doesn't have to wait for a transformation. Without claiming any special expertise I'd probably say your mileage simply varies, based on a host of factors, but in general CSS "decoration" will be faster than full-bore transformation, yes. Whether "all graphic application of changes" is better done with a distinct CSS layer ... that's also a more complex issue (and perhaps going a bit OT). For example, some applications need to produce HTML that works well in very old or very limited browsers: CSS may simply not be an option for them. Finding the optimal balance always comes down to very specific particulars. Cheers, Wendell
|
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
|