1

Scenario

We have a java application that hosts the logic for parsing the various versions of ddex specs. For every new ddex release, we currently maintain a respective mapper to map the xml to our Application classes. This is how the process looks like:

DDEX XML -> JAXB -> JAXB Auto Gen. JAVA Classes -> Mapper Code -> Application Classes

This design is not maintainable on a long run. It leads to lot of code duplication and repetitive test efforts for every ddex release which contains a lot of fields as it is from the previous version.

I will like to know how can such a system be designed better. We are open to switch to other xml parsers too, if required.

Note: I saw this answer, but wanted to know any ddex-specific ideas too. Plus the answer is more than 10yrs old, so wanted to check if there is anything else available now.

Vipul Jain
  • 386
  • 3
  • 14

1 Answers1

1

In my view, JAXB (and data mapping technologies generally) are the wrong choice when you have to deal with frequent schema change. I've seen projects come badly unstuck on this.

Rather than mapping specific schema structures to specific Java classes, you should be using a generic tree model such as DOM, JDOM2, or XOM (DOM is the oldest, most popular, and worst of the three - I would go with JDOM2).

With a generic tree model, you can design your application to be resilient to most changes in the incoming XML.

Alternatively, use an XML-oriented programming language such as XSLT or XQuery.

I'm not familiar with ddex so this answer is not specific to that environment.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164