[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML API specification

• From: Len Bullard <cbullard@h...>
• To: David Durand <dgd@c...>
• Date: Fri, 28 Feb 1997 13:54:18 -0600

David Durand wrote:
> 
> At 11:53 AM -0600 2/28/97, Len Bullard wrote:
> >David Durand wrote:

> >This kind of argument went on in VRML and was wisely rejected.
> >The commitment to a CORBA IDL is a commitment to a syntax for the spec
> >and not a lot else.
> 
> If Gavin's information is correct (and I assume it to be so) this is false.

What is in the spec and what can be done with the spec are not the same 
issue.  Use of the tool is something one can do with a spec.

> IDL means that we get language-specific bindings for several languages
> including Java and C++, simply by applyiing an automated tool. So there are
> concrete technical advantages to using IDL, though we must apply those
> tools for the programmers, so that I don't have to find an IDL tool to use
> XML with my Java codebase.

And if we commit to Java we get only one.  An IDL plus an automated tool 
gets us multiple bindings.  Sounds good to me.  An IDL minus an
automated 
tool gets us a syntax for interface definitions.  It is also one 
which is a serious contender for world wide standardization of 
distributed objects.  OMG has its supporters and distributed objects 
are the way things are going for real.
 
> > The commitment to JAVA for implementation
> >is only a commitment to a slow language.
> 
> Again, verifiably false. There is no reason that native-code Java compilers
> cannot exist. Languages aren't slow -- implementations are. Something you
> learn sometime in your first 2 years of college...

Guns don't kill; people kill.  Something one learns 
from a bumper sticker.  So, I avoid people and love my guns. ;-)
 
> > The commitment to it
> >in the spec is a commitment to SUN.  That should never be
> >a part of the spec.  It should be something the spec can
> >be bound to.  It will anyway, but XML's future is in many
> >languages and platforms.
> 
> An argument for IDL, against Java (and one that I made, by the way, so that
> we appear to be in raging agreement).

Yes indeed.  Now, on the other hand, if we need a sample implementation 
(not a reference yet), then the Java language is IMO, the best contender 
given the ubiquity of native support in the dominant frameworks.
 
> >Groves, as Richard Light pointed out, at the very least
> >gives us authoritative names for things.
> 
> Which is good _if_ the names are meaningful to the audience, and is bad if
> they make things harder for people. I agree that _gratuitous
> incompatibility_ with grove terminology would be bad, but I think we should
> evaluate it on its inherent merits, and give it an epsilon of advantage
> (for being a standard) over any equivalent non-standard terminology. On the
> other hand if it seems to create confusion we should deep-six it without
> hesitation.

Yes.  I think Richard is trying to get some of that out for 
folks to look at.  If it is a wad of badly applied terminology, 
then deepsix it.  Doesn't this make life a bit hard for the 
DSSSL folks?

> > As Joe English
> >and Gavin Nicol have pointed out, the bindings here are
> >trivial.
> 
> Great, then in the worst case, we need (at most) a "grove dictionary" if
> groves turn out to be confusing. Naturally, if they are not confusing we
> should use them.

Right.  The question is, for what, and the answer may be, for 
the authoritative names of SGML properties and only where the properties 
used are those used in XML.  IOW, not gratuitous use, but specific 
and normative use.  This alignment could help anyone who is 
obligated to precisely define the relationship of 
their XML development to SGML development, and vice versa.

> > If that is the case, then groves-IDL-Whatever(Java, C++, etc)
> >is the right thing to do.
> 
> Well, something certainly is the right thing to do (we hope). Care to be
> more precise?

That was as precise as needed.  If a grove plan defines the SGML
Properties, 
and then, the XML properties, use the grove plan to define 
the IDL.  Use the IDL to compile to -> Whatever.  
 
> I now incline to IDL, with compiled-into-Java and compiled-into-C++
> versions for IDL ignorati like myself...

I can live with that.  The original question was whether the 
grove and grove plan concepts would be useful to defining the API 
given their use in DSSSL, HyTime, and SGML.  XML is a proper 
subset of SGML, so on the surface, it appears that the SGML 
properties can be subset to express XML properties.

Because at least some part of this group has invested resources 
to understanding them, and perhaps others should look, it is an 
issue that can come to consensus pretty quickly.  The IDL is the 
more necessary piece because it leads directly to implementation.
While implementation is the focus, because I assume and API 
spec leads to a document kept somewhere, choosing the definitional 
approach is the most vital decision to be made right now.

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@i... the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@i...)

• References:
  • Re: XML API specification
    • From: dgd@c... (David Durand)
  • Re: XML API specification
    • From: dgd@c... (David Durand)

• Prev by Date: Re: XML API specification
• Next by Date: Trees versus event streams
• Previous by thread: Re: XML API specification
• Next by thread: Re: XML API specification
• Index(es):
  • Date
  • Thread