Copyright c by Ronald Bourret Last updated: This list has not been updated since As a result, information may be out of date and products may no longer be available. Special thanks go to Sean Sullivan, who provided the initial list of links and who continues to provide valuable input, and to Brendan Macmillan, to whose list of links I shamelessly helped myself and who also helped me understand and categorize tools for working with XML and objects.
This allows applications usually data-centric to manipulate data that has been serialized as XML in a way that is more natural than using the DOM. For example, consider the following sales order document: This is what XML data binding is used for. Based on this mapping, the product can then create objects from XML documents "unmarshalling" or serialize objects as XML "marshalling". For a more complete explanation of XML data binding, see the papers below.
The first set of limitations are round-tripping limitations. These are limitations on what is preserved if an XML document is round-tripped through an XML data binding product -- that is, its contents are transferred from an XML document to a set of objects and back again.
All XML data binding products can round-trip elements, attributes, and text, as well as the hierarchical relationships among them. However, most XML data binding products cannot preserve anything else, such as comments or entity references.
As a general rule, this is not a serious problem, since applications that use XML data binding tend to be interested only in the data in an XML document, rather the way in which it is represented.
While XML data binding products preserve the hierarchical relationships between elements and attributes, most are probably? For example, products can probably serialize most data-centric XML correctly, but probably cannot handle things like repeating sub-sequences.
This is generally a problem only to the extent that an XML data binding product generates documents that are invalid because of sibling order.
The reason for this is that such constructs do not have corresponding constructs in object languages. Comments and processing instructions.
Most XML data binding products do not preserve comments and processing instructions. The reason for this is that these do not map easily to object schemas, since they can occur anywhere in the document. I do not know if XML data binding products preserve the XML declaration, including the encoding and standalone declarations. The second set of limitations are features. Again, this is not a serious limitation for most applications -- either they do not need the feature or there is a workaround.
Incoming XML documents commonly have a structure that differs from the structure of the classes used by the application. This is particularly true when XML Schemas are defined externally, such as with industry-standard schemas. As a result, applications commonly use XSLT to transform incoming documents to a format which can be mapped to their classes.
Some of the mapping languages used by XML data binding products can perform a limited set of transformations, which may reduce the use of XSLT. JiBX has a particularly good mapping language in this respect.
It appears that no XML data binding products can operate on document fragments. That is, they cannot extract data from one or more fragments of an XML document, expose that data using schema-specific objects, and re-write those fragments to the document, leaving the rest of the document unchanged. This is a real problem in workflow scenarios, where a series of applications works on a document, each modifying part of the document and passing it to the next application.
As a workaround, applications must extract and re-insert fragments themselves. Design-Time Products These products require configuration before they can be used. A few allow classes to be annotated with mapping information or derive from an XML mapping class. The advantage of design- time products over run-time products is that they are usually more flexible in the mappings they can support. Run-Time Products These products do not require any configuration. Instead, they can be used directly in code to serialize and de-serialize objects as XML.
In exchange for ease of use, the user generally has no control over how classes are mapped to XML. For example, some products use Java Reflection to discover property names and use these as element type names. Others exploit the ability of languages such as Python to use the fields in a class without first declaring them. Still other products use proprietary XML languages for storing data. I have undoubtedly missed some products and am not current on others. Because of this, be sure to check your favorite vendor's Web site for the latest information.
Also, please note that I have not used any of these products. I have gathered product information from documentation, Web sites, and product reviews and therefore encourage you to use this information as an introduction only.