Lists Home |
Date Index |
- From: Peter@ursus.demon.co.uk (Peter Murray-Rust)
- To: email@example.com
- Date: Fri, 27 Jun 1997 18:34:34 GMT
In message <Pine.OSF.3.93.970627162429.950Hfirstname.lastname@example.org> Norbert Mikula writes:
> On Fri, 27 Jun 1997, W. Eliot Kimber wrote:
> I have also had a similar idea a few days ago.*1
> I would like to know whether you guys think it makes
> sense to go even further and have also this kind of
> calls for attributes and other potential "nodes" in
> our parse tree. I would think so.
Yes. Definitely. The more of this that can be generalised, the better.
Essentially quite a lot of JUMBO is involved in this sort of processing
and I'd be more than happy to try to migrate JUMBO's ideas towards an API.
My Node class (== Element, more or less) has nearly 100 member functions,
and I'll try to post them as a javadoc API (just needs locating on the WWW).
> Now the question remains if this approach should substitute
> the event base stream that built the bottom layer of
> our XAPI-J discussion. I think the event based approach
> should still form the base. Many people, I believe,
> feel still very comfortable with it.
I feel very comfortable with the event stream API and I would certainly
not substitute it. Essentially JUMBO can consume Elements from either an
NXP-like event stream, or a Lark-like tree structure. It may be useful to
identify those objects such as Element and Attribute that are relevant to both
environments, and there could be an Element/Attribute Factory sitting on top
of both (but leaving them exposed as well for those who need the lower level).
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to email@example.com the following message;
List coordinator, Henry Rzepa (firstname.lastname@example.org)