Lists Home |
Date Index |
- From: "Bill la Forge" <firstname.lastname@example.org>
- To: "Graham Moore" <email@example.com>, <firstname.lastname@example.org>, <email@example.com>
- Date: Fri, 9 Oct 1998 09:31:44 -0400
From: Graham Moore <firstname.lastname@example.org>
>I think Tyler is right when he says that having access to the parser events
>is useful. While the SaxInput should remain in the domBuilder interface
>could one extension be something more raw.
> build(URL xml); for example. The domBuilder can create its own
>parser set itself to be the event sink and build the DOM from the events.
Looking more and more like the Docuverse DOM.openDocument(Object).
There should be some minimum set of parameter types which should
be supported for conformance, SaxInput being one of them. URL is
easy enough that mandating it shouldn't be a problem.
But aside from SaxInput and SaxException, do we really want to mandate the
use of SAX events? If we can find a way around that particular mandate,
then we allow a tighter coupling between the parser and DOM construction,
and allow for a more complete extraction of information from the document.
This is where wrappers and delegation have something to offer. As long as
the wrapper or a mixin of the aggregate are responsible for the events,
only that code which handles the events need be vendor-specific:
Simple application code that implements Element can be in
the DOM tree directly, but would not have access to parse events.
Application code held by a wrapper or participating in an
aggregate would support an api or a design pattern (which
is to say, JavaBeans), which benefits indirectly from parse events.
>I still prefer a delegation mechanism to a simple inheritance. More
>With delegation you could have a Node object, a functional object and a
>The functional and Node objects are added to the delegator object (mix them
>in). The delegator is then the reference to the composite functionality.
>There is no dependency between the functional and Node objects.
I believe it is appropriate to support the alternatives here via the
specification, on a per-element basis.
>> I prefer a framework which says nothing about how the object tree is
>> even if there is an object tree. The application should be responsible
>> doing this...
>The application is responsible. Its the application that gives the
>domBuilder the construction rules / element bindings / delegation
>that it wants applied. And the app gets back a functional dom or set of
Further, the application should be able to select different domBuilder's
from different vendors and use them all together.
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)