Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
