Hi Michael, Thanks for your thoughts. Kindly see my comments below. On Sun, Apr 12, 2009 at 2:09 AM, Michael Glavassevich <[email protected]> wrote: > From a performance perspective I think it would be good if the DOM being > built could be shared with assertions which start within the scope of the > outermost assertion which triggered the DOM construction. Then you're only > ever building one DOM tree at a time. These details could be hidden beneath > the interface which the schema validator talks to so that it is possible to > plug in other XPath 2.0 engines which may not necessarily take DOM as an > input.
I have written the implementation in this manner only. You could review the code, when I submit the patch :) At present, there is very minimal code in XMLSchemaValidator.java which requires it to build a DOM for assertions processing. I have tried my best to have OOP qualities like, loose coupling and high cohesiveness. I want to share that, I have made the provision to provide the assertion processor to the Xerces Schema engine via a system property. It would be something like following, java -Dorg.apache.xerces.assertProcessor=fullyqualifiedclassname XMLSchema11Test test.xml test.xsd This system property can also be provided via an API call (for e.g., using the Java API System.setProperty). In the absence of this system property, the XML Schema processor would default to the Psychopath implementation. Using the system property will make it easier for users to plug in any compliant XPath 2.0 processor. To write a new assertions processor for Xerces (like, XMLAssertPsychopathImpl), the users would have to extend a class XMLAssertAdapter (which I have written), which internally implements the interface, XMLAssert. Using XMLAssertAdapter is another convenience feature for the users (so they don't have to implement all the methods of the interface, XMLAssert). > > We could be clever about how much of the DOM we build by analyzing the XPath > expressions, for example a/b/c isn't going to need to look deeper than 3 > elements so could avoid constructing many subtrees if we recognize that they > won't be traversed. Might also be interesting to have a smarter path when > the input to the validator is DOM where we could just use the application's > DOM instead of building a new one. This is a nice idea. I'll try to implement it. It might require some thinking, and we might do this in a future iteration. -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
