Markup Object Events (MOE)


Packages Markup Object Events (MOE) - a set of classes for working with portions of XML documents as objects. Wrappers which present MOE objects as other objects. An area for testing out strange new MOE possibilities. The package contains a set of classes for working with portions of XML documents as objects. factory classes for creating MOE objects. Extra classes for supporting namespace contexts in documents. a set of classes for testing MOE. A Swing view of MOE objects. Visitor classes for checking MOE stuff, modifying MOE per rules.


Markup Object Events (MOE)

Introduction | Warnings | Future Directions | License | Acknowledgments | Download

MOE is a set of classes built to provide support for SAX filters which need to maintain portions of documents as trees. This makes it much easier to write code which uses a SAX foundation but can still perform limited processing based on the contents (though not following siblings) of elements.

Introduction - Why MOE?

Java developers already have two very different APIs for working with XML generically: the W3C Document Object Model (DOM) and the Simple API for XML (SAX). The DOM's tree-based approach to documents provides complete accessibility to document content at the cost of a large memory footprint, while SAX's event-based approach saves memory but at the cost of presenting only a small portion of the document at any given time.

Markup Object Events (MOE) seeks a middle ground between these two approaches. Developers frequently want to combine the efficiency of SAX processing with some degree of DOM accessibility. While it is possible to combine the two interfaces, the API designs are quite different, forcing programmers to work with two very different styles. MOE offers a unified style that supports both event- and tree- approaches.

Like SAX, MOE supports an event-passing approach to reading XML documents. Like DOM, MOE describes XML documents as objects, rather than a series of strings and characters. The interfaces between classes generating and receiving MOE events can be much simpler because they only need to pass and receive objects implementing a single interface. Developers can work with these objects much like they work with SAX events, or they can combine the objects into trees representing portions of XML documents.

MOE also supports the transfer of information at different granularities. While SAX always sends attributes with the startElement() event and the DOM presents complete trees, MOE permits developers to follow that approach, send attributes separately, or start with an initial list of attributes and add more later. (A set of classes which 'normalize' events to fit a particular expected form will also be a part of MOE.)

MOE is also more loosely bound to XML than either SAX or the DOM. While the basic set of classes provided with MOE is designed with XML in mind, the overall design of MOE is designed to support any kind of named hierarchical structure. Each MOE object can contain:

This fundamental structure is easily extended to support a wide variety of content types. While it is optimized for XML, other data structures (CSV, relational tables, ASN.1) may also be stored in this form. A rough hierarchy is all that is needed to make these objects usable in an XML environment.

MOE is also notable in that it doesn't prevent the storage of information which can't be readily expressed in XML. Annotations information in particular may not have an easily 'XML-izable' representation, but it's possible, for example, to create unordered content (attributes) which has its own unordered content (attributes). Some information will be lost if these objects are written out as XML, but applications may use that information or modify the structure of the XML to accomodate the preservation of such information.

MOE is a deliberately naive design, providing a simple interface which all components must support, but also permitting components to store far more information than the simple interface represents. Eventually I hope that MOE will include several levels of components, from deliberately simple components to components that can, for instance, keep track of the lexical forms originally used to create them. (Things like general entities used in content, CDATA sections, whitespace between attributes, etc.)

MOE objects are created with a minimum of information, but may listen for other MOE events which add content to the listening object. An MOE element object might, for instance be created from a SAX startElement event, but then listen for its child elements, halting its listening when it receives an appropriate endElement event.


MOE is thoroughly experimental, liable to change, and idiosyncratic. MOE has been created to meet a variety of different needs which may not correspond to your needs. MOE is an attempt to move into new possibilities for XML Java programming, with little reference to standards for processing XML in Java beyond the Simple API for XML (SAX). MOE is not intended at this point to interact cleanly with either the Document Object Model (DOM) or JDOM, though future work might support those models through additional interfaces.

Also, while MOE does permit you to use your own objects (supporting the CoreComponentI interface) to represent XML content, it is not designed as a generic XML->Java Objects->XML tool. For that kind of functionality, I strongly recommend exploring Quick.

Future directions

This is just getting started. The future is pretty wide-open. MOE's grown faster than I thought it would, and I suspect I'll be building it out to support whole documents in addition to document fragments.


The contents of this package are subject to the Mozilla Public License Version 1.1 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License.

The Original Code is available at

The Initial Developer of the Original Code is Simon St.Laurent. Portions created by Simon St.Laurent are Copyright (C) 2001 Simon St.Laurent. All Rights Reserved.



Thanks to Leigh Dodds, for some major suggestions on refactoring the basic interfaces.


No download is yet available.

Introduction | Warnings | Future Directions | License | Acknowledgments | Download