When fixing http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3031 tonight,
and perhaps with a clearer head after vacation, it occurs to me that the
XPathContext class has gotten pretty nasty, and needs some cleanup. It
also serves as both an XSLT context and an XPath context, which is probably
not great. Some functions such as XPathContext#getCurrentNode() are
confusing as they do not match the same phrase in the XSLT spec, and can be
easily confused with functions such as
XPathContext#getCurrentExpressionNode()!
Anyway, I think the thing to do is break XPathContext into XPathContext and
XSLTContext. The XPath context should only have access to the context
defined by http://www.w3.org/TR/xpath#section-Introduction, the basic DTM
context, and any other context deemed to be pure XPath. The XSLT context
should be derived from the XPathContext, and should allow access to that
context defined in http://www.w3.org/TR/xslt#section-Introduction, as well
as the tooling context that we allow. Along with this, there are a few
functions, such as FuncCurrent, FuncGenerateId, FuncUnparsedEntityURI, and
FuncSystemProperty which should be moved to the XSLT level. An XSLT
function will have to cast the XPathContext to an XSLTContext in order to
access XSLT state data. Obviously Xalan will always create an XSLTContext
as the XPathContext, but the XPath API should create only an XPathContext.
While I don't think the above proposal is a huge change, it could cause
regressions, so my tendency would be to wait until after the 2.2.0 GA
release. On the other hand, this will impact public APIs that people may
be using, so perhaps the change should be made now. On the other hand,
perhaps we should not muck at all with this, as perhaps there are more
important fish to fry?
Opinions?
-scott
