Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XObjects
From: Graham Moore <graham.moore@d...>
>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
dynamic,
>more powerful.
>
>With delegation you could have a Node object, a functional object and a
>delegator object
>
>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
Bindings
specification, on a per-element basis.
>> I prefer a framework which says nothing about how the object tree is
>created or
>> even if there is an object tree. The application should be responsible
>for
>> doing this...
>
>The application is responsible. Its the application that gives the
>domBuilder the construction rules / element bindings / delegation
structures
>that it wants applied. And the app gets back a functional dom or set of
>objects.
Further, the application should be able to select different domBuilder's
from different vendors and use them all together.
Bill
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
