Re: LANG: OOGL (was Re: LANG: Re: scalability (VRML))

Kevin Goldsmith (
Fri, 17 Jun 1994 15:06:29 -0700

Open Inventor vs. OOGL

On Jun 17, 11:30am, Mark Waks wrote:
> Subject: LANG: OOGL (was Re: LANG: Re: scalability (VRML))
> Mike describes how OOGL could be used in an object-oriented fashion.
> I hadn't grokked this -- I'm afraid that the OOGL docs aren't very
> clear on this point.
There are two books by Addison-Wesley documenting Inventor.

> I find myself biased against OOGL, and it's hard to put my finger on
> exactly why. It may simply be that I don't care for its look -- the
> syntax and choice of keywords aren't particularly intuitive, and I
> suspect that I would find it a hard language to program in. It's very,
> very concise, to the point of being hard-to-read, which makes the
> language feel a little archaic to me -- conciseness for its own sake
> is a very 1970's style of language design, and most stuff being done
> today recognizes that code clarity is far more important than size of
> source. (Heck, even Lisp is getting more verbose!)
Inventor is very easy to read

> On the other hand (putting on my Devil's Advocate hat for a moment),
> this may not be a telling argument. Looking at it rationally, I'm not
> actually certain that anyone is going to write this stuff by hand.
> Even HTML, a pretty simple markup language, is more and more being
> designed by people using WYSIWYG tools, instead of coded by hand. The
> odds are that almost all VRML work will be done using graphical tools,
> which will generate the resulting code. So code clarity may just not
> be an important issue.
Inventor is not so hard to edit by hand (I've been doing it for years).

> Its greatest strength is clear: there are already tools for
> manipulating it. This is no small advantage; it could give us several
> months' headstart on the project if we can adapt Geomview to our
> needs. It is, as I recall, more-or-less public domain, one of our
> critical needs. It's reasonably strong in graphical display, and
> presumably we could adapt it to new technologies as they come along.
> It's easy to parse, and it *is* concise, which ought to result in
> about as little bandwidth as we can get away with.
There are more tools for Inventor and more people using it. It is not
as consise, but we could agree on a subset of it to use. The Inventor file
format is public domain (ie: OPEN Inventor). It is available on many platforms
and it is available in both binary and ascii file formats

> On the flip side, it lacks a number of the features we've talked
> about. It really has no means of abstractly identifying objects.
> (That is, there is no way of saying, "Put a box of Kleenex there";
> you have to give a literal filename or URL.) I think we would need
> to extend it at least that far, to allow inclusion of objects
> conceptually, and allow the browser to resolve the identity of
> those objects. (Possibly an extension of the suggested "<"
> construct, giving a conceptual object name, plus a URL default.)
Inventor allows this to an extent through instancing. Inventor also
allows naming objects so that it would be easier to create an abstract object.

> It has no way of identifying non-graphical properties. We will
> need (in the long run) a way of at *least* attaching hooks to
> objects, so that when an action is performed on an object, we can
> pass that action on to a routine designed to deal with it. (And
> we need to deal with some hard issues of what it means to deal
> with an action -- are we calling local or remote routines?) Also,
> we'll need to add navigational constructs, so that there's a clear
> way of saying, "This is a door, and through it you can see Justin's
> office (which is at this URL)".
Inventor has several ways to do this.

> And God knows we need better documentation. (This isn't just a
> long-term issue -- we'll need a clearer language spec for our
> own use as we develop.)
see my first issue above

> But most of these are medium-term issues. I'd say that *if* we
> can consider ourselves to have a reasonable carte blanche to
> alter the language, so that we can add these things later, we
> could probably use OOGL as a starting point. We'll need to add
> a lot of additional constructs later (in particular, the concept
> of non-graphical properties), but it will probably suffice for
> the first cut...
I beg to differ.

> -- Justin


P.S. you can get more info from Inventor from sgi
html://, I think