We are close to releasing 1.0 of dom4j. From that point on we will have a stable API on which to build. For the 1.0 release I'd like to make a couple of minor changes. These do not affect the core Node / Attribute / Element / Document etc interfaces so they will hopefully have very minor impact. In fact they have very minimal affect on the core packages, org.dom4j and org.dom4j.io. I'd like to mention these changes now so please let me know if anyone has a problem, preferably on the list but privately if you wish. They are hopefully fairly trivial changes. 1) org.dom4j.schema package rename. Currently the org.dom4j.schema package implements XML Schema Data Types support. It was never particularly my intention to fully support full XML Schema Structure validation - that can be done by SAX parsers quite happily - though it is a possibility we could do such a thing in dom4j. Right now and for the 1.0 release this package focuses quite closely on supporting 'data types' To avoid confusion, I'd like to rename this package and the classes within it as org.dom4j.datatype and the classes from Schema* to Datatype*. This is to better describe the purpose of this package, to support 'data types' rather than schema validation per se. (This would then free up the org.dom4j.schema package for future use by any schema related classes we add to dom4j). This should have minimal impact, hopefully, since mostly people will just the referencing the org.dom4j.schema.SchemaDocumentFactory and just need to change this to org.dom4j.datatype.DatatypeDocumentFactory. Hopefully before the 1.0 release this org.dom4j.datatype package could include support for Relax NG data type support (via Kohsuke Kawaguchi of Sun's excellent MSV and XSD libraries). Also a Xerces specific handler could be written to support data type information coming from a Xerces XNI handler (if XNI exposes XML Schema Data Type information). 2) Use of Jaxen FunctionContext, NamespaceContext, VariableContext. Currently the public dom4j API does not support the setting of a function or namespace context on the XPath object. I'd like to add support for it via the Jaxen interfaces in the org.jaxen package. This allows the same implementation of function / namespace / variable context to be used across the public dom4j API and the public Jaxen API which can only be a good thing. As part of this I'd like to remove the org.dom4j.VariableContext and org.dom4j.DefaultVariableContext and use the org.jaxen.* equivalents. So if you're code is using either of these 2 dom4j classes, you'll need to change your import statements to org.jaxen.VariableContext now. Hopefully this will both make the dom4j API a little cleaner and make it a better citizen with Jaxen and other xml object models. This change will only affect those uses currently using the org.dom4j.DefaultVariableContext or org.dom4j.VariableContext. I hope neither of these changes adversely affect anyone too much. Let us know if they do! James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ dom4j-dev mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/dom4j-dev
