[This local archive copy mirrored from the canonical site: http://home.iclweb.com/icl2/mhkay/saxon.html; links may not have complete integrity, so use the canonical document at this URL if possible.]

SAXON: a Java class library for XML Applications

SAXON allows you to write your own element handlers or to use standard element handlers supplied with SAXON. Each type of element can have its own element handler, enabling you to keep your application modular. The standard element handlers provide the following services:

• Copying an element unchanged to the output
• Skipping over an element, omitting it from the output
• Supplying strings to replace the start and end tags of an element (for example to add HTML formatting)
• Recognising a group of consecutive elements of the same type (for example to generate an HTML table or list structure)
• Sorting a group of consecutive elements of the same type

• determine the element's type and attributes
• locate the element's parent or elder siblings
• set an output destination for output from this element or its children (useful when splitting an XML document heirarchically)
• write output to this destination
• associate user data with an element

XSL was an influence on SAXON, both positive and negative. I tried to use early XSL implementations and found them (a) very hard to use, and (b) very limited in capability. But I found some useful concepts in the XSL specifications and tried to incorporate corresponding facilities into SAXON.

When I first got into this field I encountered lots of formidable abstractions like groves, flow objects, architectural forms. I have gradually acquired an inkling of why some of these things are useful, but they still hurt my brain. In creating SAXON, I wanted to keep the conceptual barriers to a minimum. I hope I have succeeded.

The people who write XML parsers are very aware of performance issues, and vie with each other to process more bytes per second. I have neglected performance almost entirely, at least in the coding: SAXON is fast enough for my needs, and I haven't seen any requirements from anyone else, so I don't know how fast it needs to be. Also, I was learning Java at the same time, so I've probably made lots of beginner's mistakes.

I was much more concerned with how long it takes to write an application. I have found I can usually achieve a first-cut HTML rendition of a new XML document type in about 50 lines of new code, and have it working in half a day.

The name SAXON was chosen because it is a layer on top of SAX. Also, I was using Ælfred at the time; Ælfred of course is a Saxon king...

Conditions of Use

The software is therefore offered as is, with no warranty, support, guarantee, or implication that it is fit for any purpose. There is no implication that it will be maintained in the future. Using it may damage your health and your wealth, though it can only improve your wisdom.

With this proviso, feel free to use the software as you see fit, but do not include it in a commercial product. Distribute it onwards if you wish, provided you include this document in full.

ICL retains the copyright, and therefore all rights to commercial exploitation in the future.

THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL ICL OR MICHAEL KAY BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Distribution

User documentation is included in the form of javadoc specifications together with an API User's Guide.

The distribution includes a number of example applications.

Prerequisites:

• an XML parser with a SAX-compliant interface
• a Java (JDK 1.1) development environment