XML API specification

[Len Bullard]

Gavin Nicol wrote:
> 
> >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.
> 
> This depends. You can model a grove *soooo* simply, and it's
> actually a very useful data structure. I find grove plans to
> not be all that useful (I'd rather just model the generic grove
> and leave the grove plan up to the contructing application).

Ok.  Who would use the grove definition and for what?  It is 
policy-wise, useful to have grove definitions.  But if no one
is using them, it may not be more than that.  OTH, if it is that 
easy, it might be worth the effort.  If nothing else, it 
might be the clearest explanation by example of what groves are
and are good for.  That in turn, might help those on the DSSSL track.

> That said, slightly more concrete objects are also useful. This
> is the main difference between NXP, lark, my API, and groves: the
> level of generality in the objects. I tend toward absolute generality,
> where NXP and lark just model XML.

I'd have to side with specificity.  Getting absolute generality 
seems to be the way things like HyTime took forever to get done, 
and then, were very hard to understand because of the generality.
That is not meant to demean the effort of HyTime, but to say, 
if this is an implementation list, then the goal is to get 
implementations.  Since it is the XML development list, 
I presume implementations of XML are what is wanted.  This seems 
like a fuzzy issue.  An initial API proposal only has to 
hit the basic requirements.  I say, job one is to come to 
consensus on the basic requirements.

 > >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.
> 
> No. Java is just another implementation language (and it does have a
> number of drawbacks, like lack of continuations). The reason
> I argue for IDL is that it is language *and* platform independent. Is
> have JAVA/C++/C  and other bindings specified, and *free*
> implementations of the resolution and object instantiation mechanisms.

Ok.  Here is where I have to defer to you and Tim and the more 
knowledgeable on the list.
 
> I would also argue that distributed objects are where the world is
> heading: code replication is fine for certain things, but not for
> others.

Agree.  I would not be surprised to see an assault on HTTP's ubiquity 
start in the future.  But that is not an issue for us to discuss here.

len

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)