|04 Mar, 2003
|Final Approval Ballot
|14 Jan, 2003
|27 Jan, 2003
|Proposed Final Draft
|11 Dec, 2002
|16 Sep, 2002
|16 Oct, 2002
|Community Draft Ballot
|23 Jul, 2002
|29 Jul, 2002
|27 Jun, 2002
|29 Jul, 2002
|24 Aug, 1999
|13 Sep, 1999
|17 Aug, 1999
|23 Aug, 1999
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)
|Sun Microsystems, Inc.
|Sun Microsystems, Inc.
|TIBCO Software Inc.
Original Java Specification Request
Section 1: Identification
|Sun Microsystems, Inc.
|Name of Contact Person:
List of other organizations endorsing this JSR:
Bluestone Software, Inc.
Robert W. Bickel
1000 Briggs Road
Mount Laurel, NJ 08054
2440 W. El Camino Real, Suite 710
Mountain View, CA 94040
3900 Harney Street
San Diego, CA 92110
1289 N. Fordham Blvd, Suite A-318
Chapel Hill, NC 27514
8325 Lenexa Drive
Lenexa, KS 66214
Object Design, Inc.
Twenty Five Mall Road
Burlington, MA 01803
3877 Fairfax Ridge Road, 4th Floor
Fairfax, VA 22030
Section 2: Request
|2.1 Please describe the proposed
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
|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
|2.3 What need of the Java community will be
addressed by the proposed
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
|2.4 Why isn't this need met by existing
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
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
|2.6 Is there a proposed package name for
the API Specification? (i.e.,
javapi.something, org.something, com.something,
At this point in time we envision creating four new packages, with subpackages
These package names are subject to change as the work progresses.
|Public platform API for the XML-independent
|Public platform API for the XML-specific parts
of the marshalling framework
|Public platform API for schema-specific data
types and other support classes
|Public but non-platform API for the schema compiler
|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
|2.9 Are there any internationalization or
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.