Re: [xsl] XSL template "namespace" problem

["Jon Gorman" <jonathan.gorman@xxxxxxxxx>]

>     Hmm... I guess I'm confused about your definition of "embedded
> stylesheeet". My XML doc and XSLT file are seperate.

Well, then you really need to show more of your stylesheet or input
xml, because as I mentioned, my only guess was you're trying to do an
embedded stylesheet.


When I mean "flat"
> XSLT file, I'm talking about expanded values for <xsl:for-each> and
> <xsl:if>, etc.

Either you're generating another XSLT file OR you're generating html
output.  It's confusing to use to say you're creating a XSLT file
because that means it's either XSLT or XSL-Fo.   (Just like in many
programming languages, you can generate another program.  That's what
it sounded like you're doing from some of your description).


>I'm trying to see what my browser sees before it parses it,

It sees the XML file, nothing else.  You apply the xslt
transformation, and it produces an html file.  Just the same (in
theory) as xsltproc.

> as thats the only way I know how to debug a stylesheet.

It's a pretty good way to do it.  Running it through a variety of
parsers can help as well.  Saxon's a good bet there.

>  I'm not trying to
> do anything fancier than take XML input and produce HTML output, but with
> having Javascript at the top to do some fancy things based on the XML
> input.

Once you generate the HTML page, the XML is gone.  You can only work
with the HTML that is generated.

> In effect, I want my XSLT to create a Javascript/HTML hybrid output
> page. From what xsltproc is outputting, thats exactly what I'm getting.

Again, I'm a little skeptical since it should be spitting out errors,
but perhaps xsltproc allows bad stylesheets.  The small example we saw
had a couple of errors.  For starters, Attributes cannot contain
elements.  If you're trying to insert the value of an element or
attribute in a literal text result use
<DIV ID='{name}"  STYLE="display:none">
        <xsl:value-of select="desc"/>

Second, you seem to have freeform text outside of templates....you
really shouldn't.

Does your stylesheet look like this (in an birds-eye view without the
xml syntax)?

stylesheet
    template 1 match ="/"
        html stuff here for most of the "boilerplate, including javascript"
    template 2 match ="foo"
        might produce a html div
    template 3
/stylesheet

Notice how there's a series of templates.  This parses through the
input XML and produces the output document.  Notice it's not expanding
things, but processing the tree structure of the XML via the match.
When it hits a particular node, it will produce output.  You can
control how the tree is processed by how you use apply-children.  You
can grab values from other parts of the tree via value-of.



>
> I should ahve clarified my former statements by saying "When I take
> xsltproc's output and look at it like an HTML file, it works."

That's because it is an html file.  You're generating an html file,
nothing else.  You could create a text file too.

> I.E. the
> HTML output from xsltproc works as expected.. but IE is not. It complains
> of things like "'FirstLink' is undefined", when it appears in my
> xlsproc'ed output as a division name. That pretty much tells me that IE is
> producing output thats completely different than xsltproc.

Yes, so you need to see the output.  Look for browser plugins that
view generated output.   Try googling "view output IE".  I got a
couple of hits that look promising.  Firefox has the excellent Web
Developer plugin that allows the same behavior.


>
> I totally understand that I need more tutorials regarding XSLT and XML,
> but the truth of the matter is this: I can't find any good ones that
> explain some of the finer points of what I'm attempting to do.

There's always the specs at w3.  The XSLT one is pretty readable.  For
XML grab "XML in a Nutshell".  I've heard Michael Kay's books are good
for XSLT.

> Of course,
> because I don't have formal training in the material, I'm probably not
> explaining my problem the way it should be to get the answer I'm looking
> for. Sorry about the confusion.

It's more that you're using terms in such a way that they have the
wrong meaning and misleading people.

Jon Gorman