Allow me to promote XML.com, and specifically the Transforming XML columns.

There's a good tutorial on zvon.org.

^~Django
"Why don't we ever challenge the spherical earth theory?"

In reply to the tutorial request, there's some really good stuff on XSLT at http://www.ibiblio.org/xml/books/bible2/chapters/ch17.html -- chapter seventeen of the XML Bible is the one about XSLT, and is one of the free sample chapters.
--


($_='jjjuuusssttt annootthheer
     pppeeerrrlll haaaccckkeer')=~y/a-z//s;print;
[download]

Hi,

I think ++BUU is right. When you load the file via HTTP, Netscape has to believe of whatever content type the server claims the file is. And I'd bet that it gets text/plain as the content type (maybe that's actually what you send it through CGI.pm), or no content type, where it'll probably assume text/plain. And in a plain text file, it does not expect and thus not obey any processing instructions (like your stylesheet link)

Now, if you save the file, and load it (as a file:// URI) in Netscape, it's on it own with determining the mime type. It sees the XML ending and assumes a text/xml content type. Being in XML context now, it sees, interprets and obeys the sylesheet PI.

I wonder what the HTTP specs say about what to assume if no content type is given. If it says text/plain is to be assumed, then actually IE6 misbehaves. But maybe it allows (or even encourages) browsers to apply their own type recognitions, when the server doesn't tell. When I got time I'll eventually read into it, and update this node.

Hope this lifts the fog,
so long,
Flexx

I don't believe it's legal to have an HTTP response without a valid Content-Type. A text/plain content-type, though, is fairly common as a "fall-back" for most web servers.

The problem here is that IE never trusts the web server. When it receives what it considers a "possibly too generic" content type, it will second-guess the web server and try to figure out the content type on its own, so if it sees a text/plain content-type, but something that looks XML or HTML-ish, it will interpret it as XML or HTML.

Most people view this as really evil/stupid behavior, since it encourages misconfigured web servers. Neither Mozilla nor Netscape have adopted this practice, to my knowledge.

Yep. I didn't mean it's okay to send no content type header. And I also think that IE is an instrument of evil, but I feared to be voted down for being too honest about my opinion ;)

And I'm sure the followers of the Gates Monastery ;) will argue how smart a "feature" it is to realize an XML document even if the server wants it to be viewed as plain text (for whatever reason -- none of the browsers business...) They're like their browsers: They think they know everything better... ;)

Sorry, couldn't resist.. ;)

Cheers, Flexx

BTW, I wrote this on IE 6... >;|

Unfortunately, specifying the content type as text/xml does not solve the problem. Netscape still displays the XML as XML without applying the XSL (i.e. without transforming it into XHTML.

Alistair

Apart from finding out whether the browser actually tries to load the stylesheet (server logs?) and to check the content type (mime type "text/xml"), there are two additional differences between MSIE and NS which could wreak havoc here:

• Mozilla (Netscape's engine) does NOT parse generated html from a XSL tranformation, but rather takes the result tree from the transform literally and tries to render this. So you want to transform into valid xhtml
• MSIE still tries to conform to an early, preliminary XSLT specification which predated the official W3C version. Mozilla doesn't and you shouldn't, because as of MSXML 3.0 (roughly MSIE 5.5, one of those service packs) Explorer is fully compliant with the correct XSLT spec.

--
Cheers, Joe

Thanks, but I'm assuming that if Netscape 6.1 can handle the XML correctly (i.e. transform it to XHTML using the XSL file) when it loads it from a file, rather than being passed it from the CGI script, then the XML and the XHTML must be valid.

It would be nice to be able to capture the XHTML produced by the XSL file and then run it on W3C's validator to check that it's 100% valid, but the XHTML gets generated invisibly inside the browser. Doing a "View Source" just shows the XML. However, I'm pretty sure it is valid XHTML.

I've checked the Mozilla XSLT project page but it didn't help. It says that the stylesheet should be text/xml as well as the source, but if I use text/xml rather than text/xsl
a) Netscape 6.1 won't transform it, even when I load the XML from a file
b) IE won't transform it either.

I've also checked that I'm using the correct namespace for xsl (as specified on the Mozilla XSLT project page).

I've pretty much run out of ideas. Somebody else must have come up against this problem. There's got to be a solution out there.

I could of course just do it the easy way and get the Perl script to write the HTML. But I want to do the transformation on the client side. And I keep hearing how Mozilla/Netscape is All-Good and IE is the Pure Evil, so how come it works flawlessly in IE whereas Netscape 6.1 just acts dumb and shows me the XML?

Alistair

Ok then... It's not the content type header. It's not validity. So we need to step back and refocus, I guess...

Another idea: Don't use localhost in the href to the XSL. Use a relative link, or use your box's real hostname. Maybe your browser/server chokes on where http://localhost is, while it's fine with file://localhost.

Hamlet: There's more between heaven and earth than man can apprehend, Horatio...
Horatio: Like Quantum::Entanglement, huh?

So long,
Flexx

Thanks, but this didn't work either. Mozilla still just displayed the XML.

Maybe I should just admit defeat and say that this is a case of Internet Explorer perhaps not doing things properly, but at least doing them (unlike Netscape/Mozilla). In my opinion there's a lot to be said for getting things to work somehow rather than sticking to the rules and delivering something that just won't do what it's supposed to!

Thanks again for everyone's suggestions. Please post if you can think of anything else I might try.

Alistair