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

Mark Waks (
Fri, 17 Jun 94 11:30:12 EDT

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.

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!)

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.

(BTW, a brief tangent -- can we stop calling it the "Virtual Reality
Markup Language"? It's a serious misnomer, since we're not marking
anything up (as opposed to HTML, which *does* mark something up: text).
I propose that we keep the initials VRML (to acknowledge our roots),
but change it to stand for "Virtual Reality *Modeling* Language". I
think that expresses what we're really about considerably better...)

Okay, so let's toss away my anti-OOGL biases for a moment, and take
a hard look at it. What are its strengths and weaknesses?

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.

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.)

Related to that, we probably need a new construct, allowing us to name
an object with characteristics. ("This is the photorealistic box of
Kleenex", "This is the vector outline box of Kleenex", etc.) This
*might* be accomplished through naming conventions, but we'll need
to address the issue.

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)".

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.)

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...

-- Justin

Random Quote du Jour:

"The wages of sin are death; but after they're done taking out taxes,
it's just a tired feeling."
-- Yelizaveta Medvedeva