JeeWiz For Transforming XML

XML, a Model Language

Extensible Markup Language (XML) started as out as a simplified version of the Standard Generalised Markup Language (SGML), as did HTML, and has become a major standard for serialized data transfer and capture. It can be easily tailored for domain specific uses: HTML has an XML-compliant specification, XHTML, as has RSS, SOAP, etc. Most UML based tools can save their diagrams in XML either natively or using XMI. Web services are defined using WSDL, which also conform to XML.

JeeWiz uses XML input files as its primary source of model specification. A UML model from a typical modelling is exported into XMI (for Rational Software Modeller the saved .emf file is used), which is then transformed to a common "simplified" XML format, with all diagramming data and as much as possible of the cross-referencing removed. This becomes the specification model for the major generation transform. For a complicated model the XMI to simplified XML transform written in something like XSLT could take minutes to run, but using JeeWiz it takes a fraction of the time.

As well as transforming from XMI and WSDL, the model can just be written directly in simplified XML, using a text editor or a specialised XML editor. XML by itself is unconstrained as to the type of data it can contain. We could generate XSD (an XML constraint language with an XML syntax) in a similar way to how we generate plugins to limit UML models. This would allow XML editors to constrain the language as it's being written, to only allow the elements available in the meta-model or added in the filter, but no-one seems to use that facility and it has been allowed to lapse. Perhaps it will be resurrected as part of the Comminuty Edition initiative.

From XML to Object Tree

A transform can create its build from one or more XML input files. If there is more than one, a master (assembly) file must be specified, which contains the top element (all XML must derive from a single root element). The specification from the other files is then merged in below this top element. By default, the XML elements are all passed through to the transform, whether they correspond to meta-model elements or not and no XSD is applied. This allows patterns and templates to be written for elements that have no corresponding meta-model objects. It is however possible to use a converter that massages the XML in the same way that a filter is applied during the Eclipse plugin creation. This would allow elements to be renamed to something which does correspond to a meta-model obejct without changing the model itself.

For simple transformations, such as XMI to XML, we don't even bother with a meta-model. What JeeWiz does is create a special metal-class object called ExtraBuildComponent, which gives a minimum level of functionality, finding properties and child objects through the SAX parser and setting up them up as attributes and lists in the object. Examples of using this technique are given in the JeeWizCE distribution. The best place to look for those of you who like reading code is the JeeWiz engine's BaseBuildComponent, which all JeeWiz java meta-classes extend.

XML, a Meta-model Language

At NT/e we define our meta-model elements using XML and then use JeeWiz to convert them to java (expect for the few that are part of the engine). This allows us to use the specification to generate the plugins and documentation, etc. Method-bodies carry the implementation of the method and can't be conveniently written in XML (which is really a data definition standard). These are placed as java code in CDATA text into the method elements. The method signature is still available from the XML, for documentation or transformation to other meta-model standards.