Re: SAX and whitespace (was Re: Problems with whitespace and

Peter Murray-Rust (peter@ursus.demon.co.uk)
Sat, 03 Jan 1998 15:23:21

At 07:33 03/01/98 -0500, David Megginson wrote:
>Peter Murray-Rust writes:
>
> > - is it possible for an author to extend SAX with additional non-SAX
> > calls? [In the same way as a C library may have the standard calls and
[...]
>
>2) it may implement an interface that extends the SAX interface (say,
> by adding lexical events like comments or by adding DTD events).
>
>In either case, you could still use your application class with other
>XML parsers, but the additional methods would never be called.

I assume this is what AElfred does at present - if so, I'm very happy with
it. The way I have written things is that the Parser (AElfred) makes calls
to JUMBO - these calls are not yet implemented for Lark/NXP.

[...]
simple
> > core functionality and get that working rapidly. Then the additional
> > features can be gradually brought in. =20
>
>True, but it's never quite so simple, because every parser writer
>would implement the additional functionality in a different way. We

I am quite happy - at this stage - to have to do something different for
each Parser for the *non-core* features. If 50% of an interface is covered
by SAX, the time taken to implement the rest is a lot less than if starting
from scratch.

>have to make certain that we have covered at least the core features,
>and that means that we have to agree on what the core features are
>(I'll follow up with a separate message).

Yup - I'll reply.

>
> > - what is the position on error handling? In GUI applications like=
JUMBO
> > it's important to let the user know what is happening, so I have trapped
> > the AElfred errors.=20
>
>I think that we may want to distinguish fatal errors from warnings
>(although =C6lfred doesn't currently do so). Normally, a warning would
>print a message to a log or to STDERR, while an error would throw a
>java.lang.Error or a java.lang.Exception.

I'm not terribly keen on STDERR since this can remain hidden in a Java
console or a DOS window - and I trap all the AElfred calls I can get hold
of. (I have written a general JumboError subclass or Error, where all the
error information can be packed - different for each parser - and sent to
JUMBO. Seems to work quite nicely). There are also errors which are not
trappable in this way - for instance FileNotFoundException is not thrown
through doError().

I believe there should only be one class of error message (rather like one
class of Event in java.awt) with members like Object arg into which you can
pack anything you like. IMO error handling is going to evolve over the next
year and some sort of symbiosis will be found between the parser writers
(who "may" do some things and "must" do others) and the applications which
can take benign or Draconian action on receiving those errors. What
probably isn't much fun is if it's not easy to find out *what* the parser
has done.

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