Lists Home |
Date Index |
- From: "Bill la Forge" <email@example.com>
- To: "Tyler Baker" <firstname.lastname@example.org>, "Graham Moore" <email@example.com>
- Date: Fri, 9 Oct 1998 13:11:59 -0400
From: Tyler Baker <firstname.lastname@example.org>
>(1) There is a root element handler that is passed to the parser which
>all of the events generated by parsing the root element. If a new child
>of the root element is encountered, the root element is responsible for
>instantiating an element handler for the given element name. If no element
>handler can be instantiated then null is returned.
>(2) All of the generic events of SAX you could consider are delegated down
>the currently selected parent element which is receiving character,
>pi events among others. This is done natively in my parser and has nothing
>do with SAX per se, but this sort of framework can be easily built on top
>in a few hours I would think. I personally have had a lot of success using
>method (I will admit my opinion is biased by my own personal adulation) and
>it to be just about as straightforward as using Java Object Serialization
>framework for reading and writing object state.
>(3) No registry, bindings, or any other muckety muck is necessary. All you
>is an instantiated implementation for a root element which knows how to
>instantiate children elements who know how to instantiate children elements
>so on and so forth. It is equivalent to calling readObject() in Java
>Serialization where you need to know the root object type to case to, but
>don't have to worry about the types of any of the child objects as the root
>object knows what types they need to be cast to.
As a component programmer (distinct from an oo programmer), I attempt to
embeding in a component class any knowledge of other component classes.
(A component may know about interfaces and objects, but not other
The last thing I want is to have components created by other components
the new operator.
Coins supports this programming style--all you need is a binding for the
My own programming style depends on either factories or (preferably)
Shouldn't XObject be able to accomodate diverse styles as well?
OK, it means moving closer to the SAX DocumentHandler interface than what I
had proposed. We need a START-ELEMENT to accomodate this.
But then we've constrained the implementation. Tough choice. Perhaps a DOM-
specific set of arguments on that START-ELEMENT would be a good compromise:
public void startElement(
This again allow for greater integration with the DOM without either
precluding or excluding the use of SAX.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)