Search code examples
javaxmlxsdjaxb

How to deal with two almost identical XSD files?

I have two similar third-party services (from the same vendor) that send data to our application through XML. The XML files follow largely the same structure, but somewhere deep in the tags, there is one subtle difference.

One service sends the XML like this:

<node>
    <value>
        <![CDATA[The value]]>
    </value>
</node>

And the other has more complex needs and sends it like this:

<node>
    <value>
        <subValue>subValue</subValue>
        <description>my description</description>
    </value>
</node>

Our normal procedure is to create an XSD file and then generate the required POJO classes for it using the IntelliJ tool "Generate Java code from XML Schema using JAXB". However both files have a "value" tag but with a different datatype (one string, one complex) and it appears that this situation is simply not allowed in the concept of XSD. I have not found a way to convince IntelliJ or the jaxb-runtime library to accept this situation.

I tried declaring "value" as abstract in the xsd file and have two separate types that extend "value". This does not work as the tag is named "value" in both situations, and the parser cannot distinguish between the two.

I tried treating the entire content of the "value" tag in the second XML as a string and then process it as a separate XML file but the JAXB library did not cooperate with this.

The "value" tag is deep inside the XML structure that is otherwise equal across both services. One solution could be to generate a new set of XSD files for both services but we really want to avoid that. This would result in two sets of POJO classes generated by IntelliJ, so either we would need to completely duplicate the parsing logic (undesirable) or create wrappers for all POJOs (tedious).

It feels to me like the solution should be simple, yet I just keep running into a wall. Any hints or solutions?

Solution

  • JAXB tries to reconcile the semi-structured world of XML with the highly-structured world of Java, and it therefore doesn't work well when the XML structures are variable and unpredictable.

    Your best solution here is to preprocess your data using XSLT so it all has a common structure, before marshalling it into structured Java objects.