Hi folks, Below is a tardy summary of the Xerces2 Workshop that was held this past Monday The Xerces-2 developers conducted a workshop on Xerces 2 in Cupertino on Monday June 11. There was pretty reasonable turnout from the main Xerces-2 developers and interested parties. Much of the workshop was devoted to presentations about the current state of the Xerces 2 implementation along with discussions of various issues that need to be resolved in order for development to continue. As Andy has already posted, these slides are available at http://www.apache.org/~andyc/speeches/20010611/xerces2ws.ppt Kohsuke Kawaguchi summarized his experience porting his SAX based Relax verifier to XNI: 1. Documentation would have helped 2. He was impresssed with how easy (relatively it was to do) Here is a list of items that needs to be completed in no particular order: 1. We need a better way to update the website - this is making it hard for the Xerces 2 developers to get the word out. This is a general problem with xml.apache.org 2. We need better documentation for Xerces 2 - is there someone out there who would like to get involved with documentation? 3. We need to finalize the XNI apis. In order for this to happen, the developers would like to get some feedback from people who attempt to use the XNI apis. To date a single XNI component has been implemented. We could really use feedback from Xalan and Axis in this area. Below is a list of the big open areas in XNI. a. Validation - one of the big open areas is the redesign of the validation engine to switch from on the way out to on the way in validation. Kohsuke Kawaguchi suggested looking at things from a different angle. The current on the way out validator builds an automata checker for each element's content model and glues them together using Java flow control. Kohsuke suggested that instead we build an automata for the entire grammar at once and let the state machine handle everything. This approach seems to have a lot of benefits -- it retains the good performance of the on the way out scheme while allowing us to do a better job of reporting errors than we do now, as well as solving the problems with <any> in XML Schema. There are a few open issues with this approach including: i. handling of xsi:type ii. handling of complex type inheritance iii. modularity issue w/ schemaLocation on non-root lements. - this might be overcome by lazily creating parts of the automaton. b. XMLDTDHandler - 1 or 2 interfaces c. XMLString or String or Stringpool & consistency of their use 4. Before Xerces 2 could go into widespread use it needs to: a. Pass the entire OASIS XML conformance suite - validation in particular b. Include support for XML Schema 5. We need to create list of things that people could help out with. Ted --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
