> But aside from SaxInput and SaxException, do we really want to mandate th=
e
> 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=2E
I think you are suggesting a tighter binding - thus more open - with parser=
=20
events as opposed to SAX events?
I think this would be good, along the lines of more granularity, more=20
control more refined implementations=2E
>This is where wrappers and delegation have something to offer=2E As long a=
s
> 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=2E
> 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=2E
I think where this leads us is to a situation where an application is=20
effectively a LISP evaluator and the XML has become an S-Expression=2E
But to keep things simple the parse events should for the moment be used to=
=20
build the DOM and its mixed-in functionality=2E The app thens invokes metho=
ds=20
on the functional DOM=2E
I like the idea that XML is LISP though=2E
> I believe it is appropriate to support the alternatives here via the
> Bindings
> specification, on a per-element basis=2E
> Further, the application should be able to select different domBuilder's
> from different vendors and use them all together=2E
Yes and Yes=2E
I know this list is primarily for views but we need some confirmation of=20
what we think is good or else it appears that there is no agreement and no=20
common ground=2E
graham=2E
gdm@dpsl=2Eco=2Euk