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