File Conversion

[Anoopp Thakur]

Hi,
I have an XML file A with some structure. I have a program that uses Castor to read file A and converts it into Java Objects.
Now I need to convert file A into another XML file say B with some different structure. What I have thought is to define an interface which will have methods that would return me objects pertaining to XML file B and then use an Adapter class that would implement this interface and invoke and fetch values from the existing class(that returns objects of file A).
The client to the adapter will then marshall these objects using Castor that would give me xml file B.
Why I plan to do this is because I have more such XML files with some different structures that needs to be converted to structure of file B. So I will write adapters(that will implement the common interface) for all such files.
Is this a correct approach? Am I correct in using Adapter pattern here? Or is there a better approach to achieve this?

[Anoopp Thakur]

Forgot to mention that xml file B has a well defined xsd. It also has elements/attributes that do not have corresponding values in xml file A, so we need to have defaults for them.

[Peer Reynders]

Originally posted by Anoopp Thakur:
Now I need to convert file A into another XML file say B with some different structure.

Look into XSLT.

XSLT in Java, Processing XML with Java: Chapter 17. XSLT

[Anoopp Thakur]

Thanks for replying Peer. I have nerver used XSLT, but will go through it.
There is already an existing code that converts the source XML file to Java objects using Castor, hence I thought of using Adaptor to convert it into objects of the target type and then marshal them to target XML. Also there are two different XML source files that needs to be converted to a single target XML.
Can you give me some pointers for good XSLT tutorial or book where I can start reading from. Thanks in advance.

[Peer Reynders]

Originally posted by Anoopp Thakur:
Can you give me some pointers for good XSLT tutorial or book where I can start reading from.

I already gave you a couple of links in my previous port. Here are a couple more:
J2EE 1.4 Tutorial: Transforming XML Data with XSLT
w3schools: XSLT Tutorial

Also there are two different XML source files that needs to be converted to a single target XML.

Reading multiple input documents
Tip 3: Multiple input documents

There is already an existing code that converts the source XML file to Java objects using Castor, hence I thought of using Adaptor to convert it into objects of the target type and then marshal them to target XML.

XML is hierarchical; objects are object-oriented. There is an inherent impedance mismatch between both ("Item 43: Recognize the object-hierarchical impedance mismatch" in Effective Enterprise Java: Ch.5: State Management (PDF)) So often it doesn't make sense to force your data twice across the paradigm boundary when both input and output are in the same paradigm (e.g. XML-to-XML conversion). This makes XSLT (possibly extended with Java) the right tool for the job in the majority of cases of XML-to-XML conversion.

The Three-Legged Future

If this is one-off code that is only going to be used once and then thrown away then just "do it" completely in Castor but don't worry about patterns. If it is going to stick around a bit longer then you might as well do it right.

[Anoopp Thakur]

Thanks Peer for your invaluable comments. Neglected completely the "impedance mismatch". And sorry for missing out on the links that you provided in your earlier post. I would go through the links that you have provided.

[Buvana Ramkumar]

In my opinion using Adapter Pattern is not the best way for this logic. Instead of that use the Strategy Pattern.

[Peer Reynders]

Originally posted by Buvana Ramkumar:
Instead of that use the Strategy Pattern.

How? Where? Here is the intent of the "Strategy" pattern

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The original problem statement is something like:

I need to create XML style B data from XML style A data. I already have code that creates Style X objects from XML style A data.

How does a family of interchangeable algorithms help?

This problem reminds me of the Copy program example given in the discussion of the dependency inversion principle (DIP) - only in this case we are not copying but transforming.

So there are three main parts:

Reader for Style X objects

Transformer of Style X objects to Style Y objects

Writer for Stype Y objects

The transformer pulls the objects out of the Reader, collects as many as are necessary and then writes one or a cluster of Style Y objects out to the Writer. In this case we should have most of the code for the XML style A to Style X Object Reader. This list already shows a separation of concerns: Reader is responsible for reconstituting the Style X objects, the Transformer is responsible for transforming objects and the Writer is responsible serializing Style Y Objects. Program to an interface, not an implementation suggests that we design a "Style X Object Reader" interface to be used by the Transformer and to be implemented by the concrete "XML style A to Style X Object Reader" and that we design a "Style Y Object Writer" interface to be used by the Transformer and to be implemented by the concrete "Style X Object to XML style B Writer". The details of these interfaces depend on the actual structure of the object graphs of the Style X and Y Objects. Now repeated application of various relevant OO design principles will guide you during the refinement of your design. In the end you will probably end up with a concrete XmlAObjXReader (implements ObjXReader) which is configured with one or more input files, a concrete ObjYXmlBWriter (implements ObjYWriter) which is configured with one or more output files - both of which are then dependency injected into a concrete ObjXObjYTransformer as ObjXReader and ObjYWriter respectively.

Don't overemphasize object-oriented design patterns - there isn't a pattern for every problem - object-oriented design principles are a much more valuable and a more broadly applicable tool and all OO design patterns are based on object-oriented design principles.

See also this topic: Design Patterns...
[ May 06, 2008: Message edited by: Peer Reynders ]