XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

At 4:50 PM -0400 10/7/02, John Cowan wrote:
> Elliotte Rusty Harold scripsit:
>
> >  I've been looking at how much a subclass of Serializer should be able to
> >  do and actually can do. The speciifc context is an effort to write a
> >  Serializer subclass that outputs canonical XML. Here's what I've discovered:
>
> Here are some more use cases to guide your thinking:
>
>         An HTML Serializer that knows which HTML elements are empty
>         and generates SGML-style empty tags for them.
>
>         A Serializer that discards markup, outputting only text.
>
>         A wrapping Serializer that wraps inside markup only, leaving the
>         Infoset unchanged.
>
>         A PYX-format (ESIS-format) Serializer.
>
>         A Serializer that generates LMNL syntax.
>
>         A Serializer that generates YAML syntax.

One of the changes I've been considering based on some earlier ideas 
of John Cowan is renaming the current Serializer class XMLSerializer. 
The impetus is to allow me to create a new Serializer superclass 
which would not necessarily generate well-formed XML. For instance it 
could generate plain text, traditional HTML, RELAX NG compact syntax, 
ASN.1, S-expressions, etc. In order to make this possible it would 
provide many more hooks for subclasses for start-tags, attributes, 
end-tags, etc. This would be an abstract class which would need to be 
subclassed to be useful.

After some experimentation, I've pretty much decided against this. 
XOM 1.0 will ship with a single Serializer in the core package that 
outputs XML only.

I looked at a number of cases including alternate representation like 
PYX, classic HTML, YAML, binary infosets and more. I implemented a 
couple of these including PYX and HTML.

What I discovered at first was that I could reuse almost none of the 
code from XMLSerializer. Almost every method had to be overridden. 
Even things like indentation, line breaking, character set encoding, 
escaping of illegal characters, had very different semantics for 
different formats, if they were even allowed at all.

I considered whether there was a common subset of functionality that 
could be used by all serializers and encapsulated in a new 
superclass. There really wasn't much. I had to basically remove all 
the code that actually wrote anything onto an output stream because 
the data could change radically from one format to the next. Even the 
issue of whether to expose an OutputStream or a Writer was tricky 
since some formats needed to write text and some needed to write 
binary data.

When I was done extracting all the pieces that weren't common to most 
formats, what was left was still called a serializer, but as I looked 
at it, I came to the realization it wasn't that at all. I'd created a 
serializer that didn't actually serialize anything. Instead, what it 
was was a tree walker, and then I started thinking of all the use 
cases for a tree walker that had nothing to do with serialization. So 
I started renaming the class and methods until it stopped looking 
like a serializer at all.

Some of this may yet appear as a part of XOM, probably in the samples 
package at first. However, I think that the serialization support is 
going to be limited to pure XML for now. It will certainly be 
possible to write classes that output a XOM Document object as PYX, 
HTML, a binary encoding, or something else. However, those classes 
won't be subclasses of a common Serializer class. There's just not 
enough in common between them to make this useful.


--

  Elliotte Rusty Harold
  elharo AT metalab.unc.edu
  Processing XML with Java (Addison-Wesley, 2002)
  http://www.cafeconleche.org/books/xmljava
  http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA