Alternate implementation of a VariableStack

[An...@kyrus.com]

Hey all,
  We are using a special XML format in our application (it basically allows the
mapping of other XML formats into direct Java calls).  Anyway, we use XPath in
this format for selecting parts of another XML document... very much similar to
XSL.  We want to use variables in our implementation (you know, something like
"/whatever/something[@name=$name]"), but the way variable context works will be
slightly different in our XML format than in XSL.  The only way we can see to
implement our different variable context implementation is by extending
VariableStack and implementing different behavior there (we then would set the
VariableStack of our XPathContext to our implementation).  This is all fine and
great, except that to implement our new VariableStack, we need to get at some of
the information in VariableStack, such as the "current frame" and so on.
However, all the data members and methods that could help us (such as
getCurrentFrame) are set to private, thus forcing us to either override all
VariableStack methods and totally reimplement them ourselves, or to modify the
current VariableStack implementation and build our own custom xalan library.  We
really really want to avoid building our own custom xalan, and don't like the
idea of reimplementing the other methods.
Does anyone know, should we be using a different approach?  Are these parts of
VariableStack always going to be private?
The current implementation and use of VariableStack appears to be (I haven't
reviewed much of the source code, so I could be way off base here) closely
intertwined with the way XSL uses variables... this makes it difficult to change
the way variables are used within XPath, as the XPath code that I have looked at
(some of the different iterators, for example) make certain assumptions in the
way they use the VariableStack that make them near and dear to XSL's particular
way of variable usage.  Is there a possibility that the way XPath uses and
accesses variables could be abstracted another level, perhaps using an
interface?  This would allow developers to swap out implementations for variable
usage and give much more flexibility in this realm.

   Thanks for your consideration.