Re: [xsl] XSL template "namespace" problem

[Ian Bonnycastle <ibonny@xxxxxxxxxxxx>]

On Wed, 29 Mar 2006, Wendell Piez wrote:

> Yes, it does. (And it's what I thought I said: it does the same thing.) Using 
> xsl:text does, however, make it more obvious what is happening with those 
> fragments of Javascript code: they are being copied to the result document, 
> and nothing more. Most especially, they aren't being interpreted or executed 
> by anything (that is, until the web browser starts doing things with what it 
> gets out the other end of the transformation).

Whoops. Didn't read that part, I guess. (The part where you said it does 
the same thing.) I'll try an example using xsl:text.

> 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.

> As for your result, the term "well-formed" doesn't really apply to it one way 
> or another, since the term doesn't apply to generic HTML. (If your HTML 
> happens to follow all the XML syntax rules, it's well-formed by definition. 
> If it doesn't, it's not. That question is out of scope for your problem.)

Right.. I understand.

> 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.)

> Right, that's the down side. As I said, you've opted to start your education 
> with a blue square slope -- if not a black diamond -- when you could have 
> started with a green circle. (Apologies to you and any readers who don't ski 
> downhill. Think "skiing down steep slopes with rocks" and you'll get the 
> idea.)

Huh.. I'm not a skiier, but I like setting my sites high. My problem was 
is that I brought "black diamond" problem to the list, when I only had 
"green circle" education. I should have sat back and read more, and not 
been as impatient to try to get answers from the list. (A case of RTFM all 
over again.)

> Yup. Also less bandwidth is consumed since the smaller pieces can be passed 
> around and cached independently.

Never thought of that, but its always a plus.

> 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?

Ian