I can't comment usefully on this.
>
>As a professional SGML/XML implementor and system architect, I am very
>comfortable with this sort of approach, but I don't know how it will
>play with typical Java hackers:
>
>- Will this arrangement be too hard to understand?
Taking me as test-bed, 'no', IFF good, running examples are provided. If
only the interface is provided I suspect 'yes'. I have managed with Lark,
AElfred and NXP *because* they provided a Driver.java, EventDemo.java, etc.
which minimally and precisely exercised all their interfaces. I then
convert my application gently by tweaking each one in turn to see whether
it works for me (answer="yes").
>
>- Will it look like we're being XML purists and splitting too many
> theoretical hairs, for something that should be dead simple (what
> they consider to be just a single data format)?
Possibly. But they also come across some abstraction in java.awt - e.g. you
can't use Graphics.drawImage() without an ImageObserver argument. I've not
had the time to understand this yet, but it I set it to null, nothing awful
happens. Similarly the SwingSet is at least as complex as SAX will be.
>- Will applet writers be willing to include this many extra *.class
> files just for XML support?
What's the issue here? The *total bytecount* of the *.class, or the number
of *.class files or the number of import statements? None of these would
bother me. But I haven't considered performance issues (my own are far
worse :-)
>
>There remain strong pragmatic arguments for the
>everything-in-a-single-interface approach.
I'll leave this to you - but I wouldn't dissent from simplicity
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