> It seems from the javadoc that DTM's are considered read-only. Is this
true?
Yes. We have some plans to do an update/modify layer. No timeline though.
> I fear that this is quite slow; it builds a new DTM for the DOM for every
new XPathContext that is used, doesn't it?
Yes. You would need to share the XPathContext (which holds the DTMManager)
between invocations. But, as you said, the DTM won't be updated for edits
in this case.
> Looking at the xpath source code there are some hard coded references to
the XSLTC code
Not XSLTC. There are some hard-coded references to the Xalan package.
This is a temporary situation... we have plans to fix this.
> - easy handling of query results (that works too, but is even more
> difficult since XObjects don't implement many of the conversions that are
> specified in the API)
I'm interested to hear more concrete suggestions on this aspect.
> I'm sure that isn't all possible any time soon, but what are the current
> plans for the XPath implementation?
Right now I'm focusing on rebuilding both the XPath and XSLT parser so that
they use a parser generator (JCup or JavaCC). Once I do this I will work
on the cleaner separation of the XPath package.
Getting the updates to work properly requires working down at the DOM2DTM
level. Joe may have more thoughts on this. I think we would like this to
work, but may not be able to get to it for a while. We always welcome more
help.
-scott
Erwin Bolwidt
<[EMAIL PROTECTED] To: <[EMAIL PROTECTED]>
g> cc: (bcc: Scott Boag/CAM/Lotus)
Subject: DTM is read-only? & XPath
future?
07/23/01
11:03 AM
Please
respond to
xalan-dev
Hi,
It seems from the javadoc that DTM's are considered read-only. Is this
true?
I'm tring to use the XPath implementation without XSLT stylesheets, and I
don't particulary need DTM's, although I might switch to them if that is
needed. However, the document I'm doing xpath queries on is changing all
the time.
I find that you need to create a new XPathContext each time for a query,
or else changes in the DOM between the previous and the next query aren't
always seen by the xpath implementation.
I fear that this is quite slow; it builds a new DTM for the DOM for every
new XPathContext that is used, doesn't it?
Looking at the xpath source code there are some hard coded references to
the XSLTC code, for example in the VariableStack. So far I've steered
around that, even getting variables to work.
My requirements for this application of xpath would be:
- being able work work with context nodes from a frequently changing
documents
- context nodes in a format that supports many XML features, particulary
xsd:schema checking. That would be DOM, unless DTM can offer that too
- setting xpath variables before executing queries (that works, but isn't
easy now)
- easy handling of query results (that works too, but is even more
difficult since XObjects don't implement many of the conversions that are
specified in the API)
- pluggable XPath implementations (nice to have, making it easy to work
with data sources that have an XPath datamodel but are not XML)
I'm sure that isn't all possible any time soon, but what are the current
plans for the XPath implementation?
Wouldn't it be nice to maintain an XPath implementation that works on DOM
trees in addition to the DTM version?
Regards,
Erwin Bolwidt
