Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Take the sting out of SAX

Generate SAX parsers with XML Schemas

By Leon Messerschmidt, JavaWorld.com, 05/17/02

  • Print
  • Feedback
.

Page 2 of 4

We must reduce the work involved in writing an event-handler structure so we have more time to work on actual processing.

XML Schemas

To lighten our workload, we can automate most of the process of writing the event-handler structure. Luckily, the computer already knows the format of the XML file we will parse; the format is defined in a computer-readable DTD (document type definition) or in an XML Schema. I explore ways to use this knowledge for generating source code that removes the sting from SAX parser development. For this article, I rely on XML Schemas only. Though younger than DTDs, the XML Schema standard will probably replace DTDs in the future. You can easily convert your existing DTD files to XML Schemas with the help of some simple tools.

The first step towards building our code generator is to load the information contained in the XML Schema into a memory model. For this article, I use a simple memory model that defines only the XML entity and attribute names, as well as the entities' relationship to each other. This custom model eases the code generation process. My simplified memory model consists of two classes: Element and Elements. The former stores information for an entity, and the latter manages a list of entities.

Next, we need a mechanism that populates the memory model from an XML Schema. Because an XML Schema is also an XML file, you can use a SAX parser to parse an XML Schema and populate the memory model. In this case, a SAX parser does offer a good choice: you need to only handle events for the entity parts and attribute definitions you're interested in, and ignore extra information by letting the unneeded SAX events pass without handling them. See Resources for the XML Schema parser's full source code.

Once we load the XML Schema information into memory, we can start generating source code for our new SAX parser.

Source code templates

To generate the SAX parser's source code, I use a text-based template engine, which lets me easily insert the memory model's information into source code templates. My favorite text-based template engine is Velocity from Apache's Jakarta project.

You can easily change my source code templates to suit your needs; doing so requires a text editor for editing the templates and only a basic knowledge of Velocity's syntax.

My SAX parser source code templates generate a separate event handler, or Java class, for each complex XML entity. I define a complex entity as one that might contain other XML entities. Methods inside the complex entities' event handlers handle simple entities—that is, those entities that contain only text content and/or attributes. Because of the multiple class separation, you can more easily find the right place to insert custom source code. The separate event handlers also make code easier to maintain, should any bugs occur later.

The first source code template is for the class that handles events for complex XML entities. It creates methods for each child entity as well as temporary storage for XML attributes:

  • Print
  • Feedback

Resources
  • "Programming XML in Java," Mark Johnson (JavaWorld):