Goals: XML Event Interface

[David Megginson]

I think that the time has come to deal with a question that we have
postponed so far: the goal of a simple XML event-driven interface.
Right now, there are two completely different ideas:

1. The interface will provide standardised low-level, pre-DOM
   functionality for parsers to implement, for programmers who do not
   want to incur the overhead of using the DOM; perhaps a DOM tree
   could be built using only these interfaces.

2. The interface will provide standardised high-level, post-DOM
   functionality for parsers to implement, for programmers who do not
   want to take the time to learn the XML concepts in the DOM; perhaps
   the events could be generated from a DOM tree.

These two are actually quite incompatible: the first is an attempt to
create a less abstract user model, while the second is an attempt to
create a more abstract user model.  It's only a (happy) co-incidence
that we have managed a broad agreement so far.


LOW-LEVEL INTERFACE
-------------------

If we decided on (1), then I would consider making the interface the
core interface for Ælfred, and I would probably want to expand it
slightly to include enough functionality to build a basic level-1 DOM
tree, by adding some or all of the following information:

- an event for the doctype declaration
- an isSpecified flag for attributes
- ignorable whitespace (Ælfred should return this anyway)
- comments (yech -- _WHY_ is that in the DOM???)

This interface could use only JDK 1.0.2 features, since I have no
intention of making Ælfred incompatible with existing browsers.


HIGH-LEVEL INTERFACE
--------------------

If we decided on (2), then I would simply produce an optional add-on
for Ælfred, outside of its core interfaces (and probably in a separate
package).  I would probably make a pass-through class implementing
(the new) XmlProcessor instead of having Ælfred implement it directly,
so that the core Ælfred could still consist of only two class files.

In this case, the simple interface would be slightly less efficient,
and would include only very minimal functionality (as Tim suggests);
for anything more, you would have to use each parser's native
interface.  You could not build a DOM tree using this interface.

The question would remain open whether the simple interface could use
JDK 1.1 or JDK 1.2 features.


All the best,


David

-- 
David Megginson                 ak117 at freenet.carleton.ca
Microstar Software Ltd.         dmeggins at microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

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)