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

Subject: Re: VAJava XSLT result (perfect HTML) different from WAS 3.0 result (SAXException) - same jars, etc - Newguy QQQ
From: Gary L Peskin <garyp@xxxxxxxxxxxx>
Date: Thu, 24 Aug 2000 09:31:01 -0700
Aaron --

Since everything is working in VAJava, I suspect that the problem is
that WAS can't find the files in the first place.  I'm not familiar with
WAS but why not try substituting a little program that just opens the
file using the same URL that you're passing to your xslt engine and see
if it can find the file.  There might also be some discrepancy in the
way that your xslt engine determines absolute paths from relative ones.

If you try the substitute program, I think this may give you some
insight into why the file can't be opened.

HTH,
Gary

Aaron Alanen wrote:
> 
> 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