XML has something of a dual identity. On the one hand, in its SGML roots, XML is a way of expressing formally and rigidly structured data; DTDs and XML Schemas describe these structures. On the other hand, as seen in popular APIs -- DOM, SAX, and XSLT, but also by other XML libraries -- XML is merely a way of indicating generically hierarchical data. Unfortunately, the two sides communicate poorly. The creation of valid documents falls outside these APIs (validation is usually relegated to the parse phase). However, by using just a few special strategies one can at least get OOP objects to look a lot like valid XML.

What makes up validity?

The sorts of validity constraints you can express with a DTD differ somewhat from those you can express with a W3C XML Schema. For this tip, I'll focus on issues common to the different validity constraint specification styles.

The basic idea of XML validity is to specify what can occur inside an element, how often it can occur, and what alternatives exist for what can occur. In addition, when multiple things can occur inside an element, the order of occurrence can be specified (or left open, as needed). Let's look at a highly simplified hypothetical dissertation.dtd:

                <!ELEMENT dissertation (dedication?, chapter+, appendix*)>
<!ELEMENT dedication (#PCDATA)>
<!ELEMENT chapter (title, paragraph+)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT paragraph (#PCDATA | figure | table)>
<!ELEMENT figure EMPTY>
<!ELEMENT table EMPTY>
<!ELEMENT appendix (#PCDATA)>

In other words, a dissertation may contain one dedication, must contain one or more chapters, and may contain zero or more appendices. The various subelements occur in the listed order (if at all). Some elements contain only character data. In the case of the <paragraph> tag, it may contain either character data or a <figure> subelement or a <table> subelement. Structures can nest, but every basic validity concept is included in the example.

Back to top

Making an object look like a document

Although DOM does not do so, OOP languages have all the basic data structures to represent validity (some languages more completely than others). The trick, basically, is to create objects whose attributes are constrained so as to permit only allowable things into them. Whether this is done at compile time or runtime depends on the language used, but either approach can introduce necessary constraints. In any case, the right sorts of objects must be created for each document type, not generically for all of XML.

XML documents are hierarchical, and objects that can contain other objects as attributes are likewise hierarchical. We just need to pick a few object types for the various attributes.

At the document root -- and at other levels beneath it -- we want to specify the children that can occur, and their order. Two approaches come to mind. One option is to create a heterogeneous sequence of those things that occur in the element. Haskell and Python tuples have the nice quality of being immutable (as are, for example, Fortran records), but a regular list or array (e.g. of void pointers) can serve also. For example, in Ruby we might "declare":

                dissertation = Root.new [ Maybe_dedication.new, \
                          Some_chapter.new, \
                          Any_appendix.new ]
# Example of accessing part of root element sequence
dissertation.part[1].addchapter(some, arguments, here)

The example leaves open exactly what the classes Maybe_dedication, Some_chapter, and Any_appendix do, but contains the sequence idea. dissertation is an instance of the class Root, whose job it is to hold a sequence (and probably has a few other methods, like writing the XML or validating the current instance).

A second approach, which is easier in many languages, is to make the things occur as root attributes directly, but reserve a special attribute that indicates the sequence. For example, Java might do something like:

                public class dissertation {
    Maybe dedication = new Maybe(dedication_type);
    Some chapters = new Some(chapter_type);
    Any appendices = new Any(appendix_type);
    Seq _seq = new Seq[] {dedication, chapters, appendices};
}
/* Access is somewhat more natural now */
dissertation.chapter.add(some, arguments, here);

Back to top

Expressing quantification

We have seen that the "parts" of elements can be allowed to occur in various numbers: one or zero; one or more; zero or more. We need objects to represent these quantities. The possibility case (zero or more) is straightforward, represented by standard (homogeneous) sequences: lists, arrays, vectors, or whatever the language calls them and provides. In order to provide other behaviors, it is probably worth wrapping a basic sequence in a custom class.

The limitation case (one or zero, i.e. not more than one) has a less obvious structure. Most likely a Maybe class (and descendants like Maybe_dedication) should be built around a basic sequence object, with guards against adding more than one thing in the provided methods. This is similar to our example for the existential case (one or more). So let's look at a possible (incomplete) Python implementation:

                
                class ExistentialList(UserList.UserList):
    def __init__(self, tag=None, initlist=[]):
        if tag is None:
            raise ValueError, "Must specify tag name"
        self.tag = tag
        UserList.UserList.__init__(self, initlist)
    def __delitem__(self, i):
        del self.data[i]
        self.validate()
    def __repr__(self):
        self.validate()
        return
                '\n'.join(['<%s>%s</%s>' % (self.tag, item, self.tag)
                          for item in self.data])
    def validate(self):
        if
                not len(initlist):
            raise
                "ExistentialError", "List must have length >= 1"
            

A more robust example might add features like checks for proper item types in the .append(), .extend(), .__setitem__(), and other methods that can add to the list. A language with static typing would simply declare the type of things in the list, but would use a similar validation of size. In C++, one might use templates and generic programming to implement the general features of an ExistentialList, but specialize to subelement type.

An important feature for every object that represents a subelement is the ability to serialize itself to XML. Python reserves a "magic" method called __repr__(); other languages might use a method called .write() or .toXML(). The serialization also needs to descend recursively into children, which is handled automatically by Python with the magic method. In other cases, some manual calls on attribute objects are needed.

Back to top

Expressing disjunctions

Alternation between occurrence patterns is more difficult to express in most OOP languages. There are a few languages -- like Pascal, Fortran, and most elegantly Haskell -- that allow enumerated types (discriminated union), but these are the exception, not the rule. In most languages, you just have to add custom checking to make sure one of the allowable items is contained by an instance.

One might program polymorphic constructor functions, perhaps by providing multiple type signatures to the constructors. Each allowable thing in an alternation pattern would have a constructor (including, possibly, sequence types where quantifiers are used with the disjoins in the DTD).

However, a more flexible approach is to use a generic framework that receives its alternation list either via initialization arguments, or by inheritence from an Or superclass. Such a child might look like:

                
                class paragraph(Or):
    disjoins = (PCDATA, figure, table)

Assuming that the base functionality of the abstract class Or knows to look for a disjoins class member, this could be sufficient specialization. Naturally, guarded setters and getters need be defined in the parent (in the Python case, probably with magic methods).

Back to top

Conclusion

Using data classes with some constraints on the values contained therein allows us to mirror the validity requirements of XML documents. Containment of classes can be structured in the same manner as containment of subelements. With a good framework of base classes in place, you can basically copy a DTD directly into a set of class definitions or initializations. Instances become members of other instances, and eventually you wind up with a root object instance that, along with its attributes, has various methods for manipulating data in ways that cannot break the validity requirements (in contrast to how easily one can break validity with basic types like strings and arrays). At the end of the manipulation, the root object should have some method for writing out the XML -- recursively descending into its attribute instances -- which produces a fully grown valid XML document. An ExistentialList, for example, can contain other ExistentialList objects -- nested serialization (the print statement) works beautifully with the given sample.

A final side note: Although no examples were presented here, Eiffel's "programming-by-contract" is particularly well suited to indicating the constraints discussed in this tip.

Back to top

Resources

• XML Matters #7: Comparing W3C XML Schemas and DTDs (developerWorks, March 2001) compared DTDs and Schemas. For the issues with each, take a look there.
• XML Matters #14: Transcending the limits of DOM, SAX, and XSLT (developerWorks, October 2001) discusses the library HaXml, which enforces XML validity within a functional programming context. The abstract data types of Haskell in many ways provide a more straightforward route to enforcing validity than do OOP attribute restrictions.
• For lots more on Haskell, visit Haskell.org.
• Find more XML resources on the developerWorks XML zone. For a complete list of XML tips to date, check out the tips summary page.
• IBM trial software: Build your next development project with trial software available for download directly from developerWorks.

About the author

David Mertz uses a wholly unstructured brain to write about structured document formats. David may be reached at mertz@gnosis.cx; his life pored over at http://gnosis.cx/dW/.

Rate this article

Comments

Back to top

Table of contents

• What makes up validity?
• Making an object look like a document
• Expressing quantification
• Expressing disjunctions
• Conclusion
• Resources
• About the author
• Comments