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 10:54:08 -0400
From: Graham Moore <firstname.lastname@example.org>
>> 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
>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
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
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
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
endElement(org.w3c.dom.Element element, org.xml.sax.Locator locator)
endDocument(org.w3c.dom.Element element, org.xml.sax.Locator
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
The value of this is that the DomBuilder need not be entirely SAX
allowing a better integration between the parser and the DOM.
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)