helper classes for SAX

Peter Murray-Rust peter at
Wed Feb 25 17:15:05 GMT 1998

At 11:37 25/02/98 -0000, Michael Kay wrote:
>>"Should we add helper classes to SAX?"
>I have written a package on top of SAX which I hope to publish soon - I need
>to get it past some corporate processes

I understand the problem :-)

>I wrote it because I found I was doing the same thing repeatedly in a number
>of SAX applications. I call the package SAXON (sorry), and it provides the
>following services:
>- allows you to register a handler for a particular element type (or a
>particular element type in the context of a parent element type). The
>handler can supply methods to process the element start or end, the
>character data or ignorable white space in the element, or the start or end
>of a consecutive group of one or more elements (cf. XSL)
>- provides you with context information about the element; in particular,
>its parent and ancestors, their attributes, and also their elder sibling

This is useful. I found myself doing the same sort of thing. In a
tree-based situation it's easy - I use XLL XPtrs repeatedly. I missed these
when I came to implement some things on top of SAX.

>- allows you to associate user data with an element, so for example your
>start-element method can pass data to the corresponding end-element method
>- allows you to associate an output "bucket" with an element type, so that
>all output for that element and its children (unless otherwise specified)
>goes into that bucket. Useful for splitting documents and for limited
>re-ordering of elements

Yes. This is partly what my (very simple) SAXSplit does - splits documents
into smaller bits.

There was discussion at one stage that XML should have a transformation
language. Personally I would welcome this. XSL goes half the way in
providing a way of identifying components to be split, re-ordered,
transformed, etc. but concentrates on graphic rendering for humans. 

>- allows multiple handlers per element type
>- includes some standard element handlers for doing HTML rendition, for
>generating automatic numbering, etc

I'd certainly like someone else to write code for HTML if that is what is
being offered :-)

>Although I'm not in a position to go public with it yet, I'll be happy to
>share the current state of development with any individual who wants to


>I do realise of course that some of these facilities can be achieved by
>using the DOM instead of an event-based parser, and there is a world of

The attraction of SAX is that:
	- it is simpler for XML newbies to understand
	- you don't have to hold everything in memory
>stuff in JUMBO that I haven't expored yet. I was trying to add value to SAX

JUMBO mainly consists of large muddy footprints. Seriously, I would be
happy to lose any generic functionality from JUMBO if a better way arises.
For example, I use SAX+FOO as the parser and can see a move towards DOM for
defining the tree/grove components. When/if I'm happy to go to J1.1 I will
seriously consider the Swing JTree, though there are bits I find missing at
I am not clear what other features are modular but I am sure many are. 


Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS, Virtual Hyperglossary

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list