xsl-list
[Top] [All Lists]

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 &amp;&amp; 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>
--~--