RE: effort to port Saxon7.x to JDK1.3

This question really belongs on the Saxon list rather than here.

The only dependencies on JDK 1.4 that I know of are (a) use of the
regular expression functionality, which is quite localized and which you
should be able to remove quite easily, (b) use of the CharSequence
class, which occurs in a few places which would need to be addressed
individually (usually by code that accepts either a String or a
StringBuffer), (c) use of java.net.URI, which would have to revert to
java.net.URL.

Michael Kay

-----Original Message-----
From: owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com 
[mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com] On Behalf Of 
Xiaocun Xu
Sent: 07 May 2003 21:34
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: [xsl] effort to port Saxon7.x to JDK1.3

Thanks for the reply on confirming the approaches.

I would love to skip straight to Saxon 7.5, but it
requires JDK1.4 and my code has to work with
WebLogic6.1 which does not support JDK1.4.

I really dreaded expanding out the variables.  After
much time hoping WebLogic6.1 would certify JDK1.4, I
finally run out of time and have to deal with it, one
single case immediately confirmed my dread.  A
xsl:statement of 251 characters, now became 970
characters, it would be a nighmare to read and
maintain.  I have about 20 such cases in my code.

Is it possible and how much effort would it be for me
port Saxon 7.5 to JDK1.3_004?

Thanks,
Xiaocun

--- Michael Kay <michael(_dot_)h(_dot_)kay(_at_)ntlworld(_dot_)com> wrote:

  I thought this should have been a popular

question,

but somehow I did not find it in the archive.
  I am in the process of upgrading from Saxon

6.0.2 to

the latest 6.5.2.  While doing regression testing,

found compile errors "xsl:key may not contain
references to variables".  Guess the newer version

is

more tightly following the specs.


I'm surprised that this ever worked, but 6.0.2 is a
long time ago.

  I can expand the variables so that it no longer

use

variables in both match and use attributes, but it
will make the code less-readable and more

difficult to

maintain.  Anyone had similar problem and had a

more elegant solution?

You could skip straight to Saxon 7.4: XSLT 2.0
allows global variables
to appear in key definitions, provided there are no circularities 
(i.e., the variables must not be defined in terms of the
key).

For an XSLT 1.0 solution, I think you've identified
the only thing
possible.

Michael Kay
Software AG
home: Michael(_dot_)H(_dot_)Kay(_at_)ntlworld(_dot_)com
work: Michael(_dot_)Kay(_at_)softwareag(_dot_)com

  Attached are some of the examples of the

variables

and xsl:key currently in my code.

Thanks,
Xiaocun

<!-- Find all lineitems, key on
string(LineItemLotName) to handle 0 or 1
LineItemLotName -->
<xsl:variable name="LineItemLotColumn"

select="$LineItemHeader/cell[.=saxon:n2v($mapRFQ,'LineItemLotN

ame')]/@column"/>
<xsl:key name="lineitemLotsKey" match="//row[(_at_)row

&gt;

$LineItemHeaderRow and @row &lt; $BidHeaderRow]"
use="string(cell[(_at_)column=$LineItemLotColumn])"/>


__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day


http://shopping.yahoo.com

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


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



__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

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



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