OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: XObjects

[ Lists Home | Date Index | Thread Index ]
  • From: "Bill la Forge" <b.laforge@jxml.com>
  • To: "Graham Moore" <graham.moore@dpsl.co.uk>, <xml-dev@ic.ac.uk>, <peter@ursus.demon.co.uk>
  • Date: Fri, 9 Oct 1998 09:31:44 -0400

From: Graham Moore <graham.moore@dpsl.co.uk>
>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
>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
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
>> 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:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS