Re: [xsl] XSL template "namespace" problem
2006-03-29 17:09:59
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(_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, 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
|
|
|