No resolution for VariableStack

[Andy DePue <an...@yahoo.com>]

I posted a message on the 2nd, which I have included
at the bottom of this message, concerning our need to
use variables in XPath outside of XSL.  Because of
time constraints and because we have received no
responses concerning this issue from the Xalan group,
we must now remove XPath variable support from our
product.  To get around this issue, we will develop an
extension function for XPath (probably something like
v(varname)) and will require all of our users to
convert their XML to this new syntax.  This is
necessary as maintaining our own version of Xalan is
not an option.
If the Xalan group does decide at some time in the
future to address this issue, I still extend my offer
of help as we will need this functionality in other
products we are developing.

     Thanks,
         Andy

Contents of previous message (posted on 10/2/01):

---------------------------------------------------

Hello all,
  Back in March of this year, I wrote concerning
VariableStack (this is in the Java Xalan) and how to
modify its behavior when using XPath within your own
XML format (as opposed to within XSL).  We were having
problems because most methods in VariableStack were
defined 'final' or private and this made it difficult
to extend or modify the behavior of VariableStack. 
Well, we eventually found a solution to our problem by
carefully extending the few methods that were not
private/final.  At the time, I suggested abstracting
variables in XPath/XSL so that the behavior could be
modified in a clean way.
  Our project has been forced to revisit this issue
because we have been forced to use the latest versions
of Xalan.  In the latest versions of Xalan,
VariableStack itself has been declared 'final'.  This
is very unfortunate for our project, as it is now
impossible to extend VariableStack and our current
solution is dead.  What I would like to know is if, in
the last few months, a way has been developed to
extend or modify the behavior of variables in XPath. 
If not, then it is now impossible to modify how
variables in XPath are used short of creating one's
own custom version of the Xalan source tree (which
would be a bad option in our case).  If it is the case
that there is no way to modify variable behavior in
XPath, then I would like to propose that we develop
some kind of abstraction layer for variables so that
different variable behavior can be plugged into XPath
usage.  This is important because XPath goes beyond
XSL and is very useful for all sorts of things outside
the realm of XSL, but the current XPath implementation
in Xalan seems to be tied to how XSL specifically uses
variables.  I'm not sure how the development of Xalan
is currently setup/structured, but am willing to
contribute in any way I can to help this area move
forward (as it is critical to our current project).

   Thank you for your time and consideration,
       Andy DePue



__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1