Lists Home |
Date Index |
- From: Len Bullard <firstname.lastname@example.org>
- To: David Durand <email@example.com>
- 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
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
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
> > As Joe English
> >and Gavin Nicol have pointed out, the bindings here are
> 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
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.
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (email@example.com)