Oops. There is a downside here.
If we cache the XPathContext, and the DTMManager, and the DTM... then if you change the source DOM and call XPath again, you'll still be operating against the old DTM, which will no longer match the DOM and will probably yield incorrect results (or simply malfunction). Building a new DTM every time, though horribly inefficient, protected us from that risk. If users switch to the new XPathAPIObject approach, they could manage this by obtaining a new XPathAPIObject after modifying the DOM, thus forcing construction of a new DTM. But making the old XPathAPI into a proxy for XPathAPIObject _would_ risk breaking old code, if people are relying on the refresh-the-model-every-time behavior. Sigh. OK, revision to the proposal: Leave XPathAPI as it is -- new model every time, performance is a known issue, it doesn't handle navigation starting at the xml: declaration -- and tell everyone who has a problem with that to explicitly switch over to XPathAPIObject. We may or may not want to deprecate XPathAPI anyway. (Alternative name: PersistantXPathAPI? Ugh.)
