Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Element subclassing example

xom-interest AT

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: peter murray-rust <pm286 AT>
  • To: xom-interest AT
  • Subject: Re: [XOM-interest] Element subclassing example
  • Date: Wed, 28 Dec 2005 10:45:31 +0000

At 19:32 27/12/2005, Elliotte Harold wrote:
Kevin Y. Kim (Lists) wrote: > Hey all, > > Is there someone who's willing to share/provide a good example of > Element subclassing > and a custom node factory? Conceptually, I think it's what I want to > do based on the > tutorial, but I'm not sure how to begin. >

I have done this to support Chemical Markup Language (CML) - you are welcome to take any ideas from the latest release:

It's quite large but has a very regular format. I'd also be grateful for comments on the overall approach because it tackles a general problem that may have wider applicability. My strategy is:
- create an XML Schema to describe the chemical domain using XSD (this has many limitations but it seems the best approach at present). There are over 100 elements and 100 attributes. Many attributes and other simpleContent have restrictions (e.g. numeric, lists, minimum and maximum values). For example the elementType attributes must conform to the 118 atoms in the current periodic table for chemical elements. hydrogenCount must be a non-negative integer.
- generate code to support the functionality in the schema. There is an custom subclass for each XOM element (e.g. <atom> creates AbstractAtom. This has all the getters and setters defined by the schema. Thus atom has AbstractAtom.setElementType(String) which sets the chemical element. This automatically validates whether String is an allowed chemicalElement. Most XOM Elements have between 5 and 15 such attributes. One advantage of hardcoding these is that the application programmer gets guidance as to what attributes are allowed rather than having this fail at runtime.
- generate a custom CMLNodeFactory that creates objects of the correct type during the parse process. This delegates the domain-specific stuff to finishMakingElement (see below);
- subclass the Attribute class to support a range of simpleContent. There are about 6 hardcoded subclassed attributes. Thus getHydrogenCount() returns an instance of IntegerAttribute, whose getters and setters deal with ints rather than Strings. Further restriction is done though the setCMLValue() method on the attribute which can check for values, cardinality, etc.

Apart from the subclassed attributes, all code is now autogenerated from the schema. If a document is parsed it will automatically generate elements of the correct class, attributes of the correct subclass and will schema-validate all the attribute values on input. (Note :I do not validate content models as they are almost useless for what I want to do and I would really like to see a more flexible approach to content models).

So far the system is automatic and knows nothing about chemistry. But every XOM element can be subclassed by hand, so we have CMLAtom extends AbstractAtom. A key feature is that finishMakingElement is overridden so chemical logic can be added. For example a chemical bond has to refer to existing atoms and this requirement can be validated on input. This makes XOM an extremely powerful system - it can carry out schema- and non-schema validation on input and also carry out complex transformations of the data.

I am now starting to add handcrafted subclassed Attributes, so that there is effectively an attributeFactory. For example many of my elements can have a UnitsAttribute which points to a range of dictionaries supporting scientific units of measurement. This requires considerable validation and logic and again all this can be done on input when the attributes are created as XOM Nodes.

Because the schema continues to evolve it would be almost impossible to keep a handwritten set of subclasses in sync. Now every time I modify the schema I regenerate the abstract subclasses in less than a minute. I'd be very interested in hearing from those who have the same requirements and are tackling them in a XOM context.


Peter Murray-Rust
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road, Cambridge CB2 1EW, UK

Archive powered by MHonArc 2.6.24.

Top of Page