Simple approaches to XML implementation

[Gavin Nicol]

>Personally, I think we need an API with more power than ESIS, and
>secondarily should strongly consider a tree-style representation that can
>be optionally produced.

Agreed.

>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);
	...
   }

I have some code now that does this, and it works very well.

>It's actually a good argument for a way to request that a stored tree be
>traversed to produce callbacks just as if a parse were being created.

One kind of handler I have is one that build a tree: it also
happens to implement the XMLEventGenerator interface so that
I can use it to feed an event handler.



xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)