Simple approaches to XML implementation

Derek Denny-Brown ddb at
Tue Mar 4 18:32:10 GMT 1997

At 12:05 AM 3/5/97 +0800, Peter S. Housel wrote:
>First I want an entry point that allows the application to query
>the parser implementation what property set modules it supports
>(i.e., what's the richest grove plan available to users), and whether
>or not validation is available.
>Next, there should be an XMLEventStream object.  To create an
>XMLEventStream, you specify:
>1. The URL of the document to open.
>2. The grove plan you want, in the form of a list of property set modules.
>3. Whether or not you want validation done.

I would much rather abstract the document source, or talk about a
'Provider' or womthing like that.  It is usefull to be able to just hand
the parser a URL but that is not the only way I want to pass it documents,
and I may want it to use my URL handling code (for a shared cache) etc.  It
makes it more complicated but it increases the flexibilty tremendously.  I
agree that a grove plan is a good way to talk about event options, but it
is not the best way to pass it around.  I think htere should be an (set of)
object(s) which describe the 'grove plan' and instruct the parser what it
should hand off to the event handler.  The parser is then free to inform
the event handler/application that it does not support certain operations.

At 12:33 PM 3/4/97 -0500, Gavin Nicol wrote:
>>I think that the API includes 1 call for each kind of information that can
>>pass between the parser and the application, and _also_ an interface for
>>setting options.
>I would tend toward an event-driven interface, and an
>option-setting interface as the core parser API. For example:
>  class XMLEventHandler {
>	public boolean OnComment(String comment);
>	public boolean OnElementStart(...)
>		.... 
>  }
>   class XMLParser {
>	...
>	parser(XMLEventHandler handler);
>	...
>   }

This would be the best (performance wise) way to do this.  It works for SP
and I found it very easy to deal with in that environment.


ddb at || software-engineer || www/sgml/java/perl/etc.

xml-dev: A list for W3C XML Developers
Archived as:
To unsubscribe, send to majordomo at the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at

More information about the Xml-dev mailing list