Code doesn't sell, the "right" functionalities at the "right" times will sell.
Today we are generally not able to fullfill this need. Sometime we come closer, sometime we fail. If we come closer, the USER will change his mind - we will fail. ;-)
The issue is _not_ the data, it is the MEANING.
We are trying to seperate the the ontologies into interface, the taxonomies into interceptor and invoker. All these are stateless in the case of content. Go one step further and decouple the meta-data and hot deploy them.
Continous Build&Test on the metadata. Including Refactoring of metadata. At runtime.
There are some good examples for this: look for "XML Schmema ontology" in google or applying the MOF to JBoss.org.
ebXML and RosettaNet, in case of already defined Schema implementations, would be helpfull to be transformed by XSLT into a JBoss DD.
And, again: You can generate the whole code out of XSD meta and XML content in a standard way, but not vice versa.
Java code is only a special case of formulating MEANING, it is ugly in this. XSD is make for describe MEANING.
For example MEANING of an applied security model.
Ok, it is regarding the level of the USER of JBoss, not the level of the coder of JBoss.
Sorry for beeing one of the first.
bax
Am 05.11.2003 um 04:18 schrieb Scott M Stark:
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:
...Mhhhm, this will make some Objects statefull in the view of Ms. Meta.
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.
Decoupling of all content (class instances) from all semantics (cl/assembler) would be better IMHO.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 :)))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.
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
------------------------------------------------------- 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
