Subject: Re: [xsl] XSL template "namespace" problem From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Thu, 30 Mar 2006 15:12:06 -0500 |
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
<A HREF="javascript:Toggle('<xsl:value-of select="fname" />')"><xsl:value-of select="name" /></A>
which you posted this morning that's not well-formed.
I'm really starting to get the idea about what's well formed and whats not. Whenever I talk about well-formed, though, I'm not talking about the output... I can understand that HTML is not always well formed, and often the semantics that XSLT outputs (depending on your rules) might be nonsense to a browser, even though its proper XSLT rules.
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.
Right. But, having Javascript in the *INPUT*, as part of an XSLT file, might or might not work, depending on how the processor deals with it, or how its defined in the XSLT definition, correct?
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.
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.
I'm pretty sure I understand why, but I'm probably not using it in practice. My point to move the Javascript out the XSLT file and into its own file was kind of three fold: One was to take all the difficulty of trying to form Javascript to XSLT standards out; second was to keep from transforming Javascript by XSLT rules... it was becoming exponentially complex the more I wanted to add and three, putting Javascript in its own code and having it post-manage the resulting HTML required that I practice and improve my own JS techniques (not that has anything to do with XSLT, I'm just giving the reasons why.)
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.
So is CSS "transformation" or "application" faster than XML/XSLT transformation? If thats the case, then all graphic application of changes should be done via CSS and not XSLT, is that true?
Cheers, Wendell
====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSL template "namespace" , Ian Bonnycastle | Thread | RE: [xsl] XSL template "namespace" , Ian Bonnycastle |
AW: [xsl] XSL 1.1 -> Asking for an , news | Date | Re: [xsl] Namespaces., Kamal Bhatt |
Month |