an entry from

Piotr's R&D blog

If one does not buy into the Semantic Web premise of "one metamodel to rule them all" (aka RDF(S)/OWL) -- and this approach does seem unable to generate much traction on the web -- then one needs to worry about transforming model instances between different schema. Faced with the task many programmers will resort to an ad-hoc imperative solution in their general-purpose programming language of choice. This has disadvantages in the areas of transformation maintenance and engine features such as incremental transforms, transform traceability, bi-directional transforms, etc.

I've been thinking about the problem recently, and serendipitously found two related postings in my growing list of RSS feeds. The first was an annoucement from alphaWorks of the Model Transformation Framework (MFT). This framework defines a declarative mapping language (yay DSLs!) and an engine for transforming Eclipse Modeling Framework (EMF) models according to the mappings. The engine has some nice features like allowing incremental reconciliation of models, supporting nested (and, presumably, recursive) mappings, and allowing your own Java-coded constraints to be plugged in. The development environment (supplied as an Eclipse plugin, naturally) sports a syntax-aware mapping editor and a source-level mapping debugger.

The MTF appears to be a very nice solution if you're willing to buy into the EMF. On the other side of the fence, though, we have good ol' plain and universally-adopted XML. The canonical way to transform XML is XSLT (the XML Styling Language: Transformations; bonus points if you can name other XSL languages without resorting to Google), but since its inception the language has gained a reputation as ungainly, underpowered and unmaintainable. This is all about to change, if you believe Kurt Cagle, with the advent of XSLT 2.0. While in general I'm a fan of the loosely coupled, "scruffy" approach (as opposed to the formality of MOF and EMF), I'll have to read through the (all too long) spec to see if the details are up to scratch.

Where does that leave model transformation in Reef? I'm not sure yet. The first layer of transformations, from external artifacts to a matching low-level model (e.g. Java source code to a simplified XML model thereof), is implemented as a bit of unidirectional Java glue between parser libraries and the XML database. This works well for this relatively simple task and is unlikely to change. The next layer of transformations, from low-level model to visual UML model, is a bit of a challenge, though. These transformations need to be incremental (in more than one sense) and allow for a degree of user control. Furthermore, some of the transformations need to be able to run client-side, in an SVG browser. For the sake of sanity, I'd rather use the same code for server-side and client-side transforms, which probably leaves me with a custom JavaScript engine based on XPath 2.0, whose support is mandated for SVG 1.2. On the server-side, I'll need to cook up some way to link the engine to the XML database, probably through Rhino. Looks like some fun times ahead...