Cart
[Home] [By Thread] [By Date] [Recent Entries]
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. > >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. > >I think that we may want to distinguish fatal errors from warnings >(although Ælfred 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 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...)
|
