James Watson
Posts: 2024
Nickname: watson
Registered: Sep, 2005
|
|
Re: An Introduction to XML Data Binding in C++
|
Posted: May 8, 2007 9:05 AM
|
|
> I guess you can define 'brittle code' any way you like
> but what I mean by brittle is that insignificant changes
> cause the code to break.
>
> On the other hand, in the data binding approach, the
> client code that breaks as a result of a change will be
> flagged by the C++ compiler thanks to static typing. In
> case of DOM or your XPath-based manual mapping approach,
> with every change to your XML vocabulary you are left
> wondering (or guessing) whether the change was
> insignificant or the code is now silently broken.
This is true to some degree. We used thorough testing to make sure this did not happen. Specifically, automatic regression scripts. The reality is that the above is not nearly enough to guarantee correctness and regression testing is needed anyway.
Generally speaking, if you are working with standard schemata, they don't change. You might have a new version of the schema that may or may not require coding changes, coding changes that require remapping or just mapping changes but the standard schemata should be fairly stable. The problem was that we had a canonical schema that would have to change in addition to the code and mapping changes. The approach I am describing removes this canonical schema completely and instead uses the class as the canonical structure.
> To make it clearer what I am talking about. We'd have
> say 6 different standardized schemata for a purchase order
> that we had to support with new ones added over time. In
> order to avoid generating 6 sets of classes and writing
> thousands of lines of Java to place those orders, we
> created a canonical schema for a purchase order. Then we
> took this and generated classes from it. Then we had about
> 1000 or so lines of code to put that canonical data into
> stable business Objects. Then we had another 1000 or so
> lines of code to write the data from the usable java
> Object back into the JAXB Object.
>
> There is a much cleaner way to implement this in XSD (I
> don't know about JAXB). The idea is to define a base type
> for all purchase orders in XML Schema. This type can be
> empty or it can contain some common elements/attributes.
> Then you define your purchase orders as extensions of this
> base type. When compiling the schema to C++, you customize
> the base class by adding virtual functions that will
> constitute the interface to all the purchase orders. Then
> you customize the concrete purchase orders by implementing
> those virtual functions. The application code manipulates
> all purchase orders via the customized base class. This
> s approach is also a lot more efficient than XPath-based
> remapping.
I'm not sure I understand what you are describing here but the situation I mean is that you have many different external purchase order schemata. You have a half-dozen to a dozen RosettaNet layouts, you have a number of web service layouts, some custom layouts for important customers and them you might even have non-XML formats such as a number of EDI formats. All the data elements across these formats map into a single true set valid data elements for a purchase orders. The different layouts can be dramatically different. For example, an element that is a child in one could be a parent in another. The names of the elements and their paths are pretty much guaranteed to be different. Mapping the data from all these different formats into a canonical form with Xpath is trivial. Trying to do this with JAXB generated classes is not feasible without a lot of code. Perhaps XSD can map wildly different formats into the same class structures but I imagine that would require some sort of mapping syntax which is not unlike the approach I am describing. Also you can use similar techniques to map EDI formats or any other formats to the same classes and keep order processing logic from being duplicated across the system.
|
|
Previous Topic
