Multiple Versions of a Spec: Decorate, Inherit or Transform?
All,
We are trying to do a mapping component between our object model and a third-party standard (XML-based). There is an organization in my industry that has created a XSD specification for the transmission of data. It is full-blown with every conceivable aspect of our business contained within.
However, there are few technical challenges. We are already exporting data in this interface to two separate organizations. Both have implemented the standard, but have their own modifications (typically, ignoring whole sections of the specification and also adding additional codes of their own). Our organization does not need the entire version of the standard either.
My question: what would be the best way to avoid code duplication? I thought of three high-level options and wondered what people thought would be the best design:
> Inheritance : refactor common specification code into an abstract superclass. Then have subclasses implement each 'flavor' separately.
> Decoration : write the main specification (meaning the de facto standard) and then use the Decorator pattern on specific areas of the specification to alter behavior.
> Transformation : since this is XML, only write one mapper, for the de facto standard. Then implement a series of XSL stylesheets that will modify the results for a particular standard.
Any thoughts?
- Saish
[1416 byte] By [
Saisha] at [2007-10-2 17:16:49]
My first thought is I would go for door number 3: XSL transformation (assuming that's what you mean). Traditionally, I suffer from a tendency to keep things "inside Java" but in the case of XML processing I've come to see that there's a lot of power in XSLT.
Implementing it that way would most likely be done faster and better than either other approach. It also has the advantage that a lot more people can (or can learn to) use XSLT than Java, so you don't necessarily need a developer to make updates in the future or even accomodate a new dialect of the spec. It's been a while ago since I googled for XML tools, but there are tools that, given two XML messages, can (sort of) generate a delta between them in the form of an XLST stylesheet so this could be a starting point.
In short, XSLT is the best choice IMHO because it's more suitable for this specific task, offers more maintainability and automatic generation tools already exist.
Lokoa at 2007-7-13 18:32:27 >
Thanks for the quick response Loko!
> My first thought is I would go for door number 3: XSL
> transformation (assuming that's what you mean).
> Traditionally, I suffer from a tendency to keep
> things "inside Java" but in the case of XML
> processing I've come to see that there's a lot of
> power in XSLT.
I agree. I was an evangelist about XSLT a few years ago, but performance issues (memory and speed) led me away. If only $%$#! Microsoft had made the browser perform the transformation on the client sooner, I think it would have been the de facto standard now, even over JSP's.
> Implementing it that way would most likely be done
> faster and better than either other approach. It also
> has the advantage that a lot more people can (or can
> learn to) use XSLT than Java, so you don't
> necessarily need a developer to make updates in the
> future or even accomodate a new dialect of the spec.
> It's been a while ago since I googled for XML tools,
> but there are tools that, given two XML messages, can
> (sort of) generate a delta between them in the form
> of an XLST stylesheet so this could be a starting
> point.
>
Did not know there were code generation tools like that, but it makes total sense. That could significantly shorten our development indeed! Thanks.
> In short, XSLT is the best choice IMHO because it's
> more suitable for this specific task, offers more
> maintainability and automatic generation tools
> already exist.
I agree. Really, we do not 'care' that there are different flavors of the specification (except that we have to output them successfully). From our perspective, the data model itself is the source of truth. Supporting the actual standard seems to make sense, just maybe not the half-dozen other varieties that have cropped up.
Thanks again Loko! Anyone else in favor of one of the other two methods?
- Saish
Saisha at 2007-7-13 18:32:27 >
