Hi all, The improvements for XSD namespace prefix which we are discussing in this thread, while using XSD 1.1 assertions and also CTA (when using the full XPath 2 mode) have gone into SVN.
Interestingly, solving the XSD namespace prefix issue for assertions, has fixed the same problem which existed in Xerces CTA implementation. I am satisfied with the current Xerces SVN code's functional capabilities for assertions and CTA. The new Xerces SVN code after this commit has a same functional capability as before, but with the XSD namespace prefix enhancements, which we discussed in this thread. It would be great, if anybody may like to test the newly committed code, and suggest possible improvements. Regarding the performance enahncements which Michael suggested, relating to compiled assert XPath expression, I'll try to do that asap. This particular performance enahcement looks doable to me. But the amount of changes that will happen to Xerces code relating to this, look like can be large, and may affect quite a few of Xerces APIs. So I wish to do this change a bit cautiously, and can submit code for review, after I am able to do enough testing. Also I think, there is no need for a panic about performace, relating to the current SVN code, for Xerces assertions. The users would not likely notice any performance degradation for most commonly used XSD 1.1 schemas, that will use Xerces assertions. Also given the computer's CPU capabilities, and memories which users currently use for software applications, I personally see this issue not a major risk at the moment. But definetely, we should try to improve the Xerces implementation in this regard. On Fri, Nov 13, 2009 at 11:41 AM, Michael Glavassevich <[email protected]> wrote: > Hi Mukul, > > I had a deeper look at what's currently in SVN and it's quite different than > what I would have expected to see, perhaps in part due to the design of > PsychoPath. I was hoping to find a separation between the parsing / > processing of the XPath expressions and their evaluation during schema > validation, with the work for the XPath parsing / processing being done once > during schema loading (or deferred until it's actually needed). This is a > pattern supported by the JAXP XPath API, where you compile [1] an XPath > expression and use / reuse this compiled expression for evaluation [2] many > times. The compilation step is potentially expensive but you only pay for > this cost once. > > It seems that we pay for the XPath parsing every time we evaluate an > expression. I can't imagine that would have good performance. I'm hoping > that there's a better way of doing this where the parsing of the XPath > expression is done during schema loading which is also the best place to be > pulling the namespace bindings from the schema document. > > What do you think? > > Thanks. > > [1] > http://xerces.apache.org/xerces2-j/javadocs/api/javax/xml/xpath/XPath.html#compile(java.lang.String) > [2] > http://xerces.apache.org/xerces2-j/javadocs/api/javax/xml/xpath/XPathExpression.html#evaluate(java.lang.Object) > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: [email protected] > E-mail: [email protected] -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
