As a follow up to the e-mail I sent out on the 2nd
(which I have included the text at the bottom of this
message for convenience), I have been poking around in
the current VariableStack and it looks like you all
have been busy. :-)
VariableStack is completely redesigned from the last
time I looked at it, and it looks highly optimized for
speed. Here are some obversations I made today
(please correct me if I am wrong):
1. Variables are now referenced by index (usually
relative to the current stack frame) on the stack,
rather than name. The first stack frame, that is, the
stack frame beginning at absolute 0, is for global
variables. Some ramifications of this new design:
a. Actual stack access is more effecient.
b. Details of resolving names is removed from
VariableStack (though there is a helper function for
resolving names if needed).
c. Requires the user of VariableStack to maintain
own mapping of names to index.
2. The size of a new stack frame is specified when the
frame is "linked". This requires the "user" of
VariableStack to know in advance how many variables
will be needed in that stack frame.
I'm impressed with the effeciency of this stack.
However, the trade off appears to have been
customization, with VariableStack itself being
declared 'final'. If you refer to my original e-mail,
you will see that we use XPath independently from XSL.
I'll go into some additional detail here:
We have our own XML dialect that uses XPath, and XPath
variables, much like XSL, but with differences. For
variables, the differences are as follows:
In XSL, variables work much like they do in Java or C:
when you enter a new stack frame, you only see the
variables within that stack frame. You cannot see the
variables in other frames.
Our dialect makes use of variables so that when you
enter a new "context" (or stack frame), you can see
all the variables that have been set up to that point
in any preceeding calling contexts. For example, if
context "A" sets a variable "X" to value "Hello", then
calls (enters) context "B", "B" will see that "X" is
set and equal to "Hello". At this point, "B" can set
"X" to another value, and "B" and anything that "B"
calls will see this new value for "X". However, when
"B" returns and we are back in "A", "X" will revert to
its original value of "Hello" so that as far as "A" is
concerned, the value of "X" never changed.
Of course, I realize that since VariableStack is now
declared 'final', it is fully intended to be an
internal class used in internal ways. However, the
current implementation is highly dependent on how XSL
uses variables, even though XPath itself is
conceptually independent of XSL. This means that
using XPath outside of XSL is possible, as long as you
only desire to use variables exactly like XSL does.
The result is that the current linking stack frames
and indexed variables are not compatible with how our
application uses variables. For example, our usage of
variables works better with names, rather than index,
as you can just search up through the previous stack
frames for the variable name and retrieve the first
value with that name you find. With index, you would
have to know what the index for that variable name was
in each of the preceeding stack frames as you
searched.
What is the proper procedure to begin discussions on
this topic? Again, I am totally willing to contribute
in any way necessary. If this cannot be resolved in a
timely manner, we will have to remove variable
functionality from our product.
Thank you,
Andy DePue
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
