helper classes for SAX

[Peter Murray-Rust]

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
>elements.

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
>collaborate.

:-)

>
>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
present.
I am not clear what other features are modular but I am sure many are. 


	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

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