ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Article:
  The State of JAXB: Availability, Suitability, Analysis, and Architecture
Subject:   Love the JCP
Date:   2004-05-10 12:27:07
From:   satyak
Response to: Love the JCP

Mike,


Thanks for the comments. XML being structured data, XML's applications go beyond "cross platform data transfer". XML is being used in quite unexpected domains including inside of a given program space never crossing the boundaries. Take configuration files. The data never crosses the process boundary. One can argue that configuration files can benefit from XSDs. This is a choice and doesn't have to be mandatory.


Another example is data transformation where data is read from a database and transformed to become an html page in a web environment. The data can be retrieved either as an object or dom depending on the eventual transformation. Again although one can define an XSD for it, lot of times one doesn't need it. Having this choice simplifies the development effort.


Take another case where one has to send an email in html format on the back end based on certain program data. Here one should be able to populate a corresponding complex object and apply xslt to the resulting xml. Again one can publish XSD, but I don't think the value of it is as significant as the case you have quoted.


Databases are becoming increasingly XML aware. For example, with reasonable approximations you can send a large XML to a database and have the database automatically do multiple inserts for the entire data one time. In this scenario one can create java objects in memory to match the schema and insert the object tree directly into the database one time. Again having XSDs for all possible cases will be a proliferation of files not to mention the factory generated code in your applications.


Same with work flow applications where multiple components work on a single data set as it passes through a work flow stream. Defining XSDs, in my opinion, is going to make the maintenance process quite cumbersome as there are so many aspects of the same data structure needs to be maintained.


I also think that XSD is one way of defining structured data. Object languages like Java and C# is another way to define structured data. Both have their strengths and weaknesses. I have felt that having XSD optional would have been nice. Some of the postings here have suggested other means to serialize java objects as xml if one doesn't need the XSD support. Perhaps not a bad idea.

These aspects can not be new and I am sure well discussed in the JCP, and they have good reasons to base JAXB on XSD to cover the more common cases and still be an efficient implementation. But that leaves a gap for cases where XSDs are not that necessary and the programmer has to seek alternatives.


Thanks

Satya