We are now using OASIS Namespace and Schemas in our 2.x trunk. While I handled changes to all modules and also started providing backward compatibility based on our previous discussion [1] to the biggest set of processors responsible by dealing with composite processing, there are still more things to do (and I'd appreciate help from all the community).
- Backward compatibility The approach I took is to provide a tuscany-module-xml-osoa module that would handle the specific osoa schema, contribute processors and unit test the specific processors. This is demonstrated in assembly-xml-xsd-osoa and assembly-xml-osoa. This would allow maximum flexibility for us and any users/embedders as it allows us to produce distributions that are OASIS specific (e.g.: by picking up only the default OASIS specific modules) or backward capable (e.g by picking up OASIS and OSOA set of processors). Note that, while I have done the work for our assembly-xsd and assembly-xml, I'd need help from the community to get the same pattern applied to the other extensions. - What's next Update assembly model based on the latest Assembly spec draft and current schemas Finish bring-up of modules outside java/modules to use appropriate ns/schema Provide extension-xml-osoa modules that would be used for backward compatibility Please let me know if you have questions/comments... And "the pool is open" for everybody to help bringing this up. [1] http://www.mail-archive.com/[email protected]/msg05656.html -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/
