Re: [xsl] XSL template "namespace" problem
2006-03-30 05:58:29
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [xsl] XSL template "namespace" problem, (continued)
- Re: [xsl] XSL template "namespace" problem, Ian Bonnycastle
- Re: [xsl] XSL template "namespace" problem, Jon Gorman
- Re: [xsl] XSL template "namespace" problem, Wendell Piez
- Re: [xsl] XSL template "namespace" problem, Jon Gorman
- Re: [xsl] XSL template "namespace" problem, Ian Bonnycastle
- RE: [xsl] XSL template "namespace" problem, Michael Kay
- Re: [xsl] XSL template "namespace" problem, Wendell Piez
- Re: [xsl] XSL template "namespace" problem, Ian Bonnycastle
- Re: [xsl] XSL template "namespace" problem, Wendell Piez
- Re: [xsl] XSL template "namespace" problem,
Ian Bonnycastle <=
- Re: [xsl] XSL template "namespace" problem, Wendell Piez
Re: [xsl] XSL template "namespace" problem, G. Ken Holman
Re: [xsl] XSL template "namespace" problem, David Carlisle
RE: [xsl] XSL template "namespace" problem, Ian Bonnycastle
RE: [xsl] XSL template "namespace" problem, Wendell Piez
|
|
|