Re: XML API specification

Len Bullard (cbullard@hiwaay.net)
Wed, 26 Feb 1997 11:05:24 -0600

Tim Bray wrote:
>
> At 10:59 AM 26/02/97 -0500, Gavin Nicol wrote:
> >Quite. I think we can model these objects in a number of ways
> >though. I would personally like to define the objects in IDL
> >*and* SGML... (for information on IDL etc. look at www.omg.org).
>
> Fortunately, we're not starting from scratch. We have two strawman
> interfaces on the table right now, NXP and Lark. Seems to me that
> since XML is particularly likely to be processed in the client, you
> could do a lot worse than a Java API - the idea of having a
> set of superclasses for Element, Attribute, and so on seems awfully
> desirable to me.

Milowski proposed this approach two years ago on comp-text-sgml and in
private email for the same reasons. I think it is a very desirable
spec to have.

Could we go through the bone of contention up front
and just settle it: are grove and grove plan definitions of
use to an object-oriented API design? Really just asking here,
so this gets settled and doesn't crop up again and again.

> [Confession - I've been too busy putting proper
> attribute defaulting in Lark (hard!) to even get around to looking at
> the NXP interface, so I have no comment as to which straw I prefer at
> the moment].
>
> I would propose seriously that Java be the basis of the first
> cut at an API spec; it is really very pleasingly clean,
> and also has the virtue that ideas can be tested more or less
> instantly because there's running parser code to graft them
> onto. - Tim

Wouldn't that also avoid the platform wars issues by settling
on a virtual machine? Given that most operating systems are
supporting it or will be soon, that it is fast becoming the
choice of other web languages for "heavy lifter" scripting,
I agree it looks ideal.

Java is rather slow, but perhaps that is implementation and
not an issue for an API spec. Correct me if that is wrong.

len