Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 31: XML Data Binding Specification

Stage Access Start Finish
Final Release Download page 04 Mar, 2003  
Final Approval Ballot View results 14 Jan, 2003 27 Jan, 2003
Proposed Final Draft Download page 11 Dec, 2002  
Public Review Download page 16 Sep, 2002 16 Oct, 2002
Community Draft Ballot View results 23 Jul, 2002 29 Jul, 2002
Community Review Login page 27 Jun, 2002 29 Jul, 2002
CAFE   24 Aug, 1999 13 Sep, 1999
JSR Approval   17 Aug, 1999 23 Aug, 1999
Status: Final
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

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

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

Specification Leads
  Joe Fialli Oracle
  Sekhar Vajjhala Sun Microsystems, Inc.
Expert Group
  BEA Systems Fujitsu Limited Hewlett-Packard
  IBM Oracle Software AG
  Sun Microsystems, Inc. TIBCO Software Inc.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1: Identification

Submitting Participant: Sun Microsystems, Inc.
Name of Contact Person: Mark Reinhold
E-Mail Address:
Telephone Number: +1 408-343-1830
Fax Number: +1 408-343-1797

List of other organizations endorsing this JSR:

Bluestone Software, Inc.
Robert W. Bickel
1000 Briggs Road
Mount Laurel, NJ 08054

CommerceOne, Inc.
Matthew Fuchs
2440 W. El Camino Real, Suite 710
Mountain View, CA 94040

DTAI, Inc.
Rich Kadel
3900 Harney Street San Diego, CA 92110
619-542-1700 x213

Extensibility, Inc.
Lee Buck
1289 N. Fordham Blvd, Suite A-318
Chapel Hill, NC 27514

Innovision Corporation
Matt Hamer
8325 Lenexa Drive
Lenexa, KS 66214

Object Design, Inc.
Dan Weinreb
Twenty Five Mall Road
Burlington, MA 01803

webMethods, Inc.
Joe Lapp
3877 Fairfax Ridge Road, 4th Floor
Fairfax, VA 22030

Section 2: Request

2.1 Please describe the proposed Specification:
The proposed specification will define an XML data-binding facility for the JavaTM 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: 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 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?
2.8 Are there any security issues that cannot be addressed by the current security model?
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?

Section 3: Contributions

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.