Hi all, I wanted to share a few thoughts about the PlanExporter library handling.
I think that the core mission of PlanExporter is to enable the export of query plan data in a complete and well-structured XML document, with a documented schema, tested by our test suite. I think that Nirmal's current patch in DERBY-4587 is extremely close to meeting that goal. The Xalan requirements in the current patch are primarily to do with how the XPlainStatisticsTest suite verifies the correctness of the generated XML. But it may be that the use of Xalan in the XplainStatisticsTest was not ideal, and we should re-evaluate that technique. Perhaps there is some other way to easily incorporate assertions about the correctness of the XML documents that are generated during the test? Or, if we can re-write the assertion logic in XplainStatisticsTest to use the older version of Xalan that is already available in the tools/java directory of the Derby trunk, that would be fine too. In fact, I think that Nirmal is already considering various approaches to these problems. Then, there are the more advanced usages of PlanExporter, which involve further techniques for taking that generated XML data and processing and formatting it for display and visualization of query plan behaviors. I think we need to be cautious about how we handle external libraries such as Xalan or JQuery in the PlanExporter functionality. Derby needs to run on an extremely broad spectrum of JVM implementations, and it also needs to retain its low footprint, both in code size and in runtime resource requirements. So I think we need to retain the basic principle that use of libraries such as Xalan or JQuery must be as optional external libraries that users can include if they wish for additional functionality, but also can omit with no ill effects (except perhaps the loss of some PlanExporter functionality). This is the way the other Derby XML-related features work. Regarding JQuery, my expectation for dynamic HTML behaviors was that the transformation of XML into well-formatted and dynamic HTML would be performed entirely by the web browser, and would not involve any Java code at all. I think that modern web browsers can do all the processing of the XML entirely in the client. I thought that we might provide one or more XSL stylesheets, which were automatically invoked by the browser using a mechanism such as <?xml-stylesheet> ( http://www.w3.org/TR/xml-stylesheet/ ), and I thought that a user who wished to combine JQuery or any other external AJAX-style library for dynamic browser behaviors would be providing and hosting the JavaScript libraries in their own web browser environment, not in something provided by us. If is is possible to provide a Java-hosted mechanism for doing this, such as the "-html" technique that Nirmal's latest patch provides, I think this would be worth doing, but I think that we can provide a very rich and full-featured visualization environment inside the web browser, using just the XML export features of PlanExporter, and so I think that focusing on making that code path solid and complete is of the most benefit to the Derby community. thanks, bryan
