XObjects

[Bill la Forge]

From: Graham Moore <graham.moore at dpsl.co.uk>
>>        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 think where this leads us is to a situation where an application is
>effectively a LISP evaluator and the XML has become an S-Expression.
>
>But to keep things simple the parse events should for the moment be used to
>build the DOM and its mixed-in functionality. The app thens invokes methods
>on the functional DOM.
>
>I like the idea that XML is LISP though.


Typically, parse events should be used to build the DOM tree.

Again, a variety of approaches and perversions should be accomodated.

Some application objects would be aware of the DOM tree and not have
any methods that are called as a result of a parse event.

At the other extreme are application objects which are unaware of the
DOM tree, but which have methods called as a result of various parse
events:

        A JavaBean may have various properties set at START ELEMENT.
        It may raise an exception as a result. The exception can then become
        a SAXParseEvent which identifies the element in the XML document
        where the exception occured.

        At END DOCUMENT, a refid may be resolved as an application
        object which supports listener registration. The referenced object
        is then called to register the event listener object which had the
refid.

Coins currently supports both of the above.

Perhaps we could generalize and say that the data held by SAX parse
events is important for building the DOM, and that that data is not
needed by the XObject, but still there may be methods that need to
be called.

The two events that I see as important here are end-element and
end-document. And the important data is Location, which is needed
to generate useful SAXParseEvents.

This suggests another interface which may optionally be implemented
by an XObject:

public interface XObjectParseEvents
{
                public void
        endElement(org.w3c.dom.Element element, org.xml.sax.Locator locator)
            throws org.xml.sax.SAXException;

                public void
        endDocument(org.w3c.dom.Element element, org.xml.sax.Locator
locator)
            throws org.xml.sax.SAXException;
}

In the above, element might be the object being called, or it might be the
wrapper which holds the object being called, or the mixin in the same
aggregate.

The value of this is that the DomBuilder need not be entirely SAX
conformant,
allowing a better integration between the parser and the DOM.

Bill


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)