Re: [xsl] XSL template "namespace" problem

Ian,

At 06:14 PM 3/29/2006, you wrote:

Notice that none of this has anything to do with Javascript. It's only job is to construct a node hierarchy containing certain elements and attributes with certain values. Those values happen to be syntactically-correct Javascript, but the XSLT engine doesn't know that and doesn't have to.
Actually, what you did with the <xsl:text> tag (one tag I didn't even know existed) is exactly what I did without it. (If that makes any sense.)

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

I've actually figured out a THIRD possibility (actually pointed to by the website http://www.quirksmode.org/ earlier)... which is removal of Javascript completely from the XLST file, and thereby making the document well-formed again.

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.

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

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.

(I hope!) I've used the docs there to put all Javascript code in a seperate file thats not processed by an XSLT processor, and therefore, doesn't get mixed in with all the well-formed mess we were talking about earlier.

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've coded the Javascript to acutally adapt to whats in the main document, and modify everything externally. All thats needed is one "kick off" call from the <BODY onLoad=""> tag. It makes the XSLT file easier to handle, too. The only problem is that I need to edit 3 different documents to create 1 web page.

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

In the interest of portability, though, its worth it. I can apply the same Javascript code and XSLT transformations to many different XML documents and create many different pages with the same effects. (Which, as far as I can tell, was *one* of the purposes of XSLT in the first place... of course, not the only one, though.)

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

This only leaves me with one question before I put this thread to bed. I've heard different people mention that the browser doesn't see XML or XSLT... just the resulting HTML (at least when it "renders" it.) But I find this confusing.. the browser *must* load the two seperate doucments (XML and XSLT files), as there is no URL reference to an HTML file... and the server doesn't generate the HTML either... so where exactly does the processor lie?

The XSLT processor is only *more or less* integrated with the browser. It's integrated in the sense that the two are wired up to work together; but it's still a separate component. Indeed, typically it's entirely separable and can be called completely independently.

XML and XSLT are delivered to a browser, which seeing this weird stuff (not the HTML stuff it's used to) says "oh, XML! please can I have it transformed?" and invokes the transformation on the file. The transformation executes; the result is nominally "HTML" even though it is held in memory and never written to disk as a file. This HTML is then displayed as if that's what the browser had received in the first place.

Is it a section of code that is called when the browser-in- question attempts to "process" an XML file with XSLT stylesheets attached? Or is it called when ANY stylesheet is attached to ANY type of file?

An XSLT processor is only invoked to apply an XSLT transformation to an XML document.

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.

Thanks again for all your help

We aim to please.

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

<- Previous	Index	Next ->
Re: [xsl] XSL template "namespace" , Ian Bonnycastle	Thread	Re: [xsl] XSL template "namespace" , Ian Bonnycastle
RE: [xsl] Filtering out duplicates , Wendell Piez	Date	[xsl] Namespaces., Kamal Bhatt
	Month

<-prev [Thread] next->	<-prev [Date] next->
Month Index \| List Home