The marshalling framework will support the unmarshalling of XML documents into graphs of interrelated instances of both existing and schema-derived classes and the marshalling of such graphs back into XML documents. These processes are governed by per-class metadata that defines the translation between an external XML document and internal instances of the associated classes. Hence the proposed specification will extend the platform to establish conventions for annotating classes with the necessary metadata. It will also define APIs for the marshalling and unmarshalling operations as well as the necessary low-level support services.

The marshalling framework should be designed so that it can be used for applications other than XML data binding. There is, for example, widespread interest in using XML as a format in which to archive graphs of arbitrary Java objects. An XML-based archiving facility should be able to use the same marshalling framework as the XML data-binding facility. (Note that the marshalling framework is not in any way intended to displace the object serialization mechanism that is already a central part of the Java platform.)

Ideally the marshalling framework will not be specific to XML. It seems unwise to tie such a general framework to a specific data format, especially since we may want to support other formats in the future. This implies that the metadata conventions and interfaces must be carefully designed so as to be independent of XML. Because this goal may be very difficult to achieve, it is a desideratum rather than a hard requirement.

The schema compiler will translate a schema into a set of derived classes with appropriate access and mutation (i.e., get and set) methods as well as the metadata required by the marshalling framework. The code generated by the compiler will check that incoming XML documents are valid with respect to the schema. The generated code will also enforce the constraints expressed in the schema, thereby ensuring that only valid documents are produced by the marshalling process.

A variety of schema-translation strategies are possible. The simplest translation results in roughly one Java class for each nontrivial schema component. A more sophisticated translation might produce interfaces or abstract classes reflecting the structures and types expressed in schema together with related classes containing the metadata and constraint-checking code. Precisely which strategy or strategies should be used by the compiler is an open question.

The schema compiler will be a command-line tool rather than an extension to the platform itself, though it may also be exposed in a public but non-platform API for direct use by development tools. As such, the most important part of the proposed specification with regard to the schema compiler will be the description of the mapping of XML schemas into Java classes.

Exactly which of the many extant XML schema languages the compiler must support is an open question. The standard currently under development by W3C's XML Schema Working Group will almost certainly be worth supporting. There are a number of other schema languages, some of which have been deployed, that may be worth supporting if there is demand. These include DCD, DDML, SOX, and XML-Data. Finally, the DTD sublanguage of XML is itself a simple schema language that is already in widespread use and may therefore be worth supporting.

javax.io.marshal	Public platform API for the XML-independent marshalling framework
javax.xml.marshal	Public platform API for the XML-specific parts of the marshalling framework
javax.xml.schema	Public platform API for schema-specific data types and other support classes
com.sun.tools.xjc	Public but non-platform API for the schema compiler

The document demonstrates the power and simplicity of data binding. While the work envisioned by this JSR might lead to a somewhat more complex facility, the example presented in the paper can serve as a vision for what the work should try to achieve.