FW: VAJava XSLT result (perfect HTML) different from WAS 3.0 resu lt (SAXException) -same jars, etc - Newguy QQQ

Subject: FW: VAJava XSLT result (perfect HTML) different from WAS 3.0 resu lt (SAXException) -same jars, etc - Newguy QQQ
From: "Alanen, Aaron" <aaron.alanen@xxxxxxx>
Date: Fri, 25 Aug 2000 08:00:49 -0700
thanks to everyone for the replies.  Most replies have suggested that its
probably because WAS cannot find the file, however if I create an obvious
error in the imported stylesheet, the parser will notify me of that error,
so it is finding the file.  Also, even in command line mode in a test
program I get the same results.  So the only difference between VAJava and
the server must be the JVM or the classpath jar files.  I'll have to play
with them some more.

thanks for the help, if you have any other suggestions let me know.  I'll
post the answer when I find it.

Aaron



<-------original message snip----------->
Hello,

I'm completely stumped.  I've read all the faqs, searched the net, read
books, its been many days without results, I really need some serious help,
I'm nearing the end of a project I designed with XSL and I'm still quite new
with it, and don't have any local guru's or resources....I'm it!  ;)

Goal:        I'm trying to include a header file in an XSL document and
match it against XML to produce HTML. - It works on my PC.

Problem:  The transformation from XML / XSL to HTML in VAJava works great on
my PC, but although I'm using same class
               files, jars, and classpath in Websphere Application Server
3.0 (S/390) I get a SAXException:

                    XSL Error: Could not parse Input XSL document!, Location
file:/users/gcc/XSL/Header.xsl, line 1, offset 1
                    XSL Error: SAX Exception, Location
file:/users/gcc/XSL/Header.xsl, line 1, offset 1
                    The markup in the document preceding the root element
must be well-formed.

I've simplified my XSL for this question, here are the files:

file 1 - [Header.xsl]

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
  <xsl:template name="Header">
    <H1>Test</H1>
  </xsl:template>
</xsl:stylesheet>


file 2 - [xslTest.xsl]

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
 <xsl:import href="/users/gcc/XSL/Header.xsl"/>
  <xsl:template match="/">
   <HTML>
    <BODY>
    <xsl:call-template name="Header"/>
   </BODY>
  </HTML>
 </xsl:template>
</xsl:stylesheet>

file 3 - XML File  (not really relevant for this, but here's a piece of it)

<?xml version="1.0" encoding="ISO-8859-1"?>
 <invoice>
    <header>
        stuff
     </header>
     <detail>
        more stuff.
     </detail>
    <footer>
        more stuff
     </footer>
 </invoice>

The only XSL code that is changed between my PC and the server is the
import:
PC:        <xsl:import href="/C:/1TempWeb/XSLText/Header.xsl"/>
Server:   <xsl:import href="/users/gcc/XSL/Header.xsl"/>

Do you have any idea why I'm getting different results on the PC and server?
My paths are the same, the jar files are the same (latest lotusXSL xalan,
xerces, and lotusxsl, xml4j ), I've tried saving the files as Unix, PC, etc,
without any changes, same error message.  There are no extra spaces, lines,
return characters, nothing is different on each platform from what I can
see.

I've tried doing a regular XSL transformation (without an include) and it
works great - but for some odd reason when I view in ascii mode the html
result is garbage, but if I look at it in binary mode, its perfect
ascii...but that's another problem I'll deal with later...  Can you help me
solve the include?

I'm thinking that WAS 3.0 may have some default jar files or something that
are being pulled in that may be older or deprecated -  But I don't know how
to find this out.  Any system properties that I pull in show my path and jar
files before the server's.  I'm really on a limb here....I can't figure out
why it works perfectly on one system and not the other, and only
xsl:includes seem to have problems.

Thank you in advance,

Aaron Alanen
Information Analyst
EDS - Global Company Contract
2222 W Dunlap Ave Ste. 300
Phoenix, AZ 85021
(602) 395-8264


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread