Re: [xsl] XSL template "namespace" problem

Ian,

I know everyone's chiming in ... we're trying to be helpful.

At 10:40 AM 3/29/2006, you wrote:

> Right now, I'm not coding for production, I'm coding for fun to get 
> a "feel" for XSLT. I probably shouldn't have asked such a question 
> on such a mailing list without fully going over a tutorial or proper 
> documentation first.
Don't worry about posting too early (or: don't worry too much; worry 
about more important things) -- we get such "exploratory" posts all 
the time. (Sometimes such posts are also "confused", but sometimes we 
all end up getting a bit confused, it being very difficult to 
disentangle implicit but sometimes mistaken assumptions on a mailing list. :-)
It's really good that you're doing something light to get a feel for 
XSLT before trying to put it to use in production. We often find 
ourselves advising people to do a little research and learning up 
front before leaping in. XSLT is one of those things where if you get 
off on the wrong foot, things can be much harder than they have to 
be, and when people rush in first, they're much more likely to make 
those early mistakes. Typically the early mistakes come out of 
misapplying a coding paradigm that doesn't belong to XSLT, and thus 
trying to make the language work in ways it wasn't designed to. What 
makes things worse is that often you can get acceptable (or what you 
consider acceptable) results doing this -- for a while -- hey, it 
works! -- until your problem crosses a certain complexity threshold, 
and you're completely stuck dead in a morass of unworkable code. If 
you had started by taking more time to learn XSLT for itself, this 
wouldn't have happened and everything would be much easier.
This having been said, experienced XSLT instructors would probably 
*not* recommend starting off with an application with as many layers 
as yours. You have (at least) three layers: XML (source code), HTML 
(display format) and Javascript (in-browser display/manipulation of 
the latter). (You may also have CSS, or maybe you're maintaining that 
inside the HTML.) This means you are thinking about *at least* two 
different layers of processing, the XML->HTML (for which you are 
using XSLT) and the dynamic HTML-in-the-browser (for which you are 
using Javascript). But you're planning to run it all inside a single 
environment, namely a browser with XML/XSLT capabilities.
Wisely, you are also (by your account) also developing and testing 
the XML->XSLT->HTML process (the "transformation") in a standalone 
processor, XSLTProc. This is good because it isolates the XSLT action 
from the Javascript action, and also makes it easier to debug, since 
you can look at the intermediate format (the HTML code) more easily, 
both to design it properly and to assess what isn't (yet) right in it 
as you develop to your design. But having come to us with 
discrepancies between what's happening in this mode and in the 
in-browser mode, as you are right to do (good call, testing them 
against each other), you've presented us with a real puzzle, because 
the XSLT you have provided could not possibly work in *any* 
conformant XSLT engine. If XSLTProc (or IE) is working, it's not 
working on the code you showed us. We know this because the stuff you posted,
> <xsl:template match="/rootnode/menuitems/item">
>     <A HREF="javascript:Toggle('<xsl:value-of select="fname" 
> />')"><xsl:value-of select="name" /></A>
>     <DIV ID='<xsl:value-of select="fname" />' STYLE="display:none">
>         <xsl:value-of select="desc"/>
>     </DIV>
> </xsl:template>
could not possibly work (as several people have mentioned). It won't 
even parse as XML, so it's not going to work as an XSLT stylesheet.
So we have to start by disentangling this -- which we do by cleanly 
separating the layers. Fortunately, you do this most easily by 
continuing in the direction you have set out. Start by using XSLTProc 
(not IE) to create an XSLT stylesheet for a  standalone XML->HTML 
transformation *without Javascript*. Run it in batch mode, outside a 
browser. Inspect the HTML results in a browser to make sure it's 
working as HTML. *Then* enhance this HTML with your scripting (you 
are moving your development temporarily to the layer up). Test it and 
fix until it works. *Then*, go back and work up your XSLT, still 
processing with XSLTProc, to the point where you are successfully 
transforming your XML source into an HTML file that contains (and/or 
calls in) the working Javascript -- still running standalone. (That 
is, in this case the HTML isn't created dynamically in the browser 
but ahead of time, and subsists as a file you can copy and upload.)
Only at *that* point are you ready to try running the whole thing 
dynamically on the client.
On the other hand, you might discover, in the process of pulling all 
this apart and putting it back together again, the joys of batch 
processing. Working on the client is cool, and there are many reasons 
you might want or need to do it. But if you're trying to get a feel 
for the language, it's also important to understand how well it works 
in other sorts of application environments (indeed, which probably 
still account and will account for the preponderance of XML/XSLT 
applications). Batch processing, or server-side dynamic processing (a 
sort of middle ground), can be a very effective way to develop and 
deploy a wide range of products from an XML source. Nor does it 
exclude doing fancy things with Javascript on the client.
Take a look at http://www.piez.org/wendell/Amsel/Amsel.html. It's an 
HTML file that lives statically on a server to be delivered to 
browsers just like any other HTML file, but it contains a significant 
scripting element (as you'll see if you hover or click on certain 
spans of text). But since creating this HTML to work correctly would 
be prohibitively difficult in native form (just take a look at the 
HTML source code and you can see what I mean), it's generated out of 
a much simpler and cleaner XML source format, using XSLT, that 
manages all the tedious aspects of coding the HTML. While the result 
isn't as groovy as XML on the client (though it happens to work that 
way too), since the HTML/Javascript is self-contained and the 
transformation out of XML has to happen only once, we still get many 
benefits from XML/XSLT -- some would say, all the most important ones.
In other words, you'll move quickest to a sure understanding of XSLT 
if you try it out in a classical architecture first, before you move 
on to all the complexities and possibilities of multi-tier processing.
Good luck,
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>
--~--