events vs callbacks (was Re: SAX2 (was Re: DOM vs. SAX??? Nah. ))

[Bill la Forge]

From: Gabe Beged-Dov <begeddov at jfinity.com>
>Given the memory management and efficiency issues, event queuing would need to be layered
>on top of, rather than instead of, the callback API. If you assumed that an event API replaced
>the callback API due to your extensibility argument, then I wonder if you couldn't provide a
>configuration parameter to the SAX driver on whether to clone or reuse the event objects.

Sounds good to me! I also recall mention of at least one true event-based parser which had
a SAX layer on top of it. Could be an interesting synergy, but I do like the independence SAX
brings us all.

>I looked at MDSAX over the weekend, and it is certainly a powerful platform for SAX based
>processing.  On the other hand, it seemed that trying to fit everything into a single filter
>network
>without any lookahead capability (would require queueing) and cumbersome lookbehind capability
>(such as in the flatten example)  is problematic. Given the constraints of making use of the
>existing
>infrastructure (SAX, XML) you have created a very flexible framework. Its not clear if the
>constraints
>are the right ones for trying to support composition of processing like you envision.


Thankyou for your kind words.

Lookahead, especially to the next sibling/peer element, could be quite handy. Especially when
processing repeating elements into a table. But an event queue might be an expensive way
to do that.

As for program composition, it really just happened. I would not have expected to be able to
do it without a DOM. Especially since id/idref is essential! But it works great. I've since cleaned
it up, but that will need to wait for the production release. 

The key was the interface to the reference table. Rather than getting back a pointer when given
an idref value, you pass in:
    o  the idref value,
    o  the object to be updated with the value associated with the id, and
    o  the associated property putter method.
The only restriction here is that the object associated with the id must implement the class which
defines the property type. (This then works for both forward and backward references.)

With IDREF's handled so neatly, and an application object associate with each element (which
becomes the value associated with the id), everything just fell in place. 

Oh yes, the next release will support complete document web processing. At least for program
composition.

Bill


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/ and on CD-ROM/ISBN 981-02-3594-1
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)