I think it's clear that we are not going to see just one API. Your
suggestion, the grove plan, Xapi-J are all viable ways forward. The point
is that Tim, DavidM, Norbert and I have all - independently - come up with
fairly simple models for APIs which have a large degree of communality.
They have the merit of being fairly simple for newcomers. None are required
to be tree-structured.
>
>public interface XmlTreeModel {
> public Object getRoot ();
> public Object getParent (Object child);
> ...
>}
>
>public interface XmlEventModel {
> public String getElementName (Object event);
> ...
>}
>
>public interface XmlEventProducer {
> public void addConsumer (XmlEventConsumer c);
> public void removeConsumer (XmlEventConsumer c);
> ...
>}
>
>public interface XmlEventConsumer {
> public void elementStarted (XmlElementEvent evt);
> public void elementEnd ed (XmlElementEvent evt);
> ...
I have looked at TreeModel in Swing and even implemented a simple JUMBO
display on it. I have to confess that, being a Dumb Browser Hacker, I found
it quite tough going. If the only interfaces to XML parsers are based on
this level of abstraction a lot of people will find them hard.
WE have been part way down this road before - look through XML-DEV
discussions 6+ months ago. I think it's essential we home in on a
moderately simple parser NOW - we know what we need to do - we simply need
to agree on the precise components and the terminology.
[...]
>
>>I acknowledge this is grossly insufficient for basing an editor on. You
>want
>>that, use the DOM. Only a few choices have design implications:
>
All I want is to get the DOCTYPE stuff from the file. AElfred now provides
exactly what I want - we just need to agree it.
>
P.
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg