What are XMLBeans and when do I use them?
In the instance when two different sub-schemas are created with the subset generation tool, and data in the XML instances of these schemas is dynamic and manipulated extensively, XMLBeans 1.0.3 should be used for Java-XML Binding. XMLBeans is a great light-weight framework that creates an object model of XML schemas. When a schema is ''compiled,'' the XMLBeans schema compiler generates the source code and classes, as well as schema snippets. By default, the code and classes are stored in packages that are derived using the namespaces provided within the schema, which can be very convenient.
However, there is a major downside. The whole reason for the subset generation tool is to provide a way to create a schema that contains only the types, elements, and attributes that are needed. Which means it is possible, and quite likely, the similar types between schemas will be different. For example, the ArrestType in one schema may contain an ArrestCharge element, where as the ArrestType may not have that element defined in different schema. The typical XSL transformation is not sufficient.
When moving and manipulating data between instances of these two schemas programmatically, driven by rules, JAX-B makes sense (for example, if similar types are defined in the schemas which differ in structure.) The namespace for the classes is the same. At runtime, the Class loader will search the class path for class definitions. When the class loader finds a class definition for the class requested, qualified by its namespace or package name, it loads it into the Java Virtual Machine (JVM) and allows the program to use it. The question is, "Which definition of ArrestType did the loader find?" There are two ways to solve the problem. First, one could generate an XMLBeans model for the entire GJXDM or NIEM, and use that library for deployment at runtime. There are pluses and minuses. The upside: one does not have to worry about having all the methods available at runtime. The object will support all of them. The downside(s): Who wants to see ''all'' of the available methods while developing the code? And, there is a bit of a performance hit as the JVM scans the library for ClassDefs.
The best way to solve the problem is to use the facility within XMLBeans to map target namespaces to Java packages. There is one more issue that is a little harder to work around. XMLBeans generates class files with the same name as the types and elements defined within the schema. So, reading the code can be a little challenging. The best suggestion here is to make your variable names meaningful and descriptive, which is a best practice anyway.