The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: September 16, 1999
XML Data Binding Specification

[August 18, 1999] XML Data Binding for the Java Platform. On behalf of the Sun Core Java Platform Group, Mark Reinhold has posted an announcement for a Sun Java Specification Request (JSR) on 'XML Data Binding' which has been submitted to the Java Community Process. The relevant document is "JSR-000031 XML Data Binding Specification", and exposition is found in "An XML Data-Binding Facility for the Java Platform."

"A particularly promising approach along these lines involves compiling, or binding, an XML schema into one or more Java classes. These automatically-generated classes handle the translation between XML documents, which must follow the schema, and interrelated instances of the classes. They also ensure that the constraints expressed in the schema are maintained as instances of the classes are manipulated. This design note reviews the basic concepts of XML and schemas, motivates and defines XML-based data binding, presents an extended example, and then outlines the requirements of a data-binding facility for the Java Platform."

And as reported: "The proposed specification will define an XML data-binding facility for the Java 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. 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. 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." Comments to: the development team or to Mark Reinhold.

References:


Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/xmlDataBinding.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org