Explain how xsd is actually the object model in terms of what the metadata handling code is using. Its directly manipulating xml instances that conform to the xsd or is there is a binding of the xsd to a java object model? If there is a binding, then that is the object model, not the xsd as that is what the code is dependent on. Why would I want to directly use some xml api and propagate around dependencies on xml parsing (which we already do to much of), rather than handling one particular externalized form of the metadata and then passing the object model around?
-- xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx
Holger Baxmann @ mac wrote:
...
Scott's posted some of the requirements in the past, e.g. removing all the xml fluff. Let the container deal with the metadata as objects.
Mhhhm, this will make some Objects statefull in the view of Ms. Meta.
Decoupling of all content (class instances) from all semantics (cl/assembler) would be better IMHO.
One of the key issues is supporting the old deployments, by translating them into the "new" object model.
jaxb doesn't cut it, it has limited/no support for changing schemas or an already established object model.
The XSD is the Object Model regardless of the content of the referenced XML, so one may apply different XSD on the same XML - or even on the XSD's. Ok, at last you may generate the .java's :)))
2.4 DD+2.4XSD <-> XSLT <-> 4.xXSD+4.xDD;
4.xXSD+4.xCMPDD <-> XSLT <-> anyServiceDD
RelaxNG & friends could provide the direction.
bax
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
