Hi Scott,
--On Montag, 20. August 2001 23:56 -0400 [EMAIL PROTECTED] wrote:
> 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.
In my previous post to xalan-dev [1] I questioned how to use the
XPathContext. Just to shortly summarize: The W3C XML Signature spec [2]
adds the new here() function to the XPath API which is defined as follows:
"The here function returns a node-set containing the attribute
or processing instruction node or the parent element of the
text node that directly bears the XPath expression. This expression
results in an error if the containing XPath expression does not
appear in the same XML document against which the XPath expression
is being evaluated."
My point is to say to get this baby to run, the XPath must have a
possibility to retrieve the information where itself occured in a document.
Does this make sense to you?
Christian
[1] Post to xalan-dev from 2001-08-20 with Subject: Philosophy: Correct use
of org.apache.xpath.XPathContext
[2] http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/#function-here
