The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 31

Find JSRs

• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs
My JCP
Register for Site
Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy
JCP Info
• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Status: Final
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0


Description:
A facility for compiling an XML schema into one or more Java^TM classes which can parse, generate, and validate documents that follow the schema.

Please direct comments on this JSR to the Spec Lead(s)

Submitting Participant: Sun Microsystems, Inc.

Name of Contact Person: Mark Reinhold

E-Mail Address: mr@eng.sun.com

Telephone Number: +1 408-343-1830

Fax Number: +1 408-343-1797

2.1 Please describe the proposed Specification:

The proposed specification will define an XML data-binding facility for the Java^TM Platform. Such a facility compiles an XML schema into one or more Java classes. These automatically-generated classes handle the translation between XML documents that follow the schema and interrelated instances of the derived classes. They also ensure that the constraints expressed in the schema are maintained as instances of the classes are manipulated.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This facility is intended to become part of the Java 2 Platform, Standard Edition.

2.3 What need of the Java community will be addressed by the proposed specification?

The proposed specification will vastly simplify the creation and maintenance of XML-enabled Java programs. Data binding automatically maps the components of an XML document to in-memory objects that represent, in an obvious and useful way, the document's intended meaning according to its schema. This allows Java programs that manipulate XML content to be written at the same conceptual level as the content itself, rather than at the level of parser events or parse trees.

2.4 Why isn't this need met by existing specifications?

The only existing Java APIs for manipulating XML are the low-level SAX parser API and the somewhat higher-level DOM parse-tree API. While it is possible to write XML-enabled programs using these interfaces, doing so is likely to be tedious and error-prone. The resulting code is also likely to contain many redundancies that will make it difficult to maintain as bugs are fixed and as the relevant schemas evolve.

2.5 Please give a short description of the underlying technology or technologies:

The proposed specification will describe two components: A marshalling framework and a schema compiler.

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.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, com.something, etc.)

At this point in time we envision creating four new packages, with subpackages as needed:

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

These package names are subject to change as the work progresses.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current security model?

No.

2.9 Are there any internationalization or localization issues?

XML itself was designed from the ground up to address such issues. A requirement of the proposed specification is that it preserve the inherent internationalizability of XML and related technologies.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No.

A design note, An XML Data-Binding Facility for the Java Platform, reviews the basic concepts of XML and schemas, motivates and defines XML-oriented data binding, presents an extended example, and outlines the requirements of a data-binding facility for the Java platform.

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.