Re: [xsl] XSL template "namespace" problem
2006-03-30 13:13:43
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
<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.
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.
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?
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.
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.)
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.
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?
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
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
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
======================================================================
--~------------------------------------------------------------------
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
|
|
|