OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Goals: XML Event Interface

[ Lists Home | Date Index | Thread Index ]
  • From: David Megginson <ak117@freenet.carleton.ca>
  • To: xml-dev Mailing List <xml-dev@ic.ac.uk>
  • Date: Thu, 18 Dec 1997 07:32:04 -0500

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@freenet.carleton.ca
Microstar Software Ltd.         dmeggins@microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS