This document *purposefully* does not propose syntax nor give examples of
syntax. It is is not dismissed but rather agreed on in theory, or
considered, then we can move on to discussing the syntax needed to
grammatically represent these ideas. I personally don't see the addition of
much in the way of syntax, maybe even only 2 or 3 keyword additions. Most of
the following represent more conceptual enhancements.
This is just a first draft of my proposal, and resulted from my interaction
with another member of the list. It may grow or shrink. Please expect other
versions to follow that are more thorough and readable in addition to trying
to be written more in the style of the working document.
* * *
A "Semantic of Objects"
=======================
Everything in VRML is an object regardless of whether it is an aggregate of
other objects such as a (.wrl) or a single object such as an instance of
"Cube". A teapot is another example of an aggregate object. "Cube" itself
isn't an object, although (to match the wording of the spec) it can be
thought of as an object used to create other more specific (or instance)
objects, but the result of using this Node by specifying its "width",
"height" and "depth" fields is an object. The resulting object may or may
not happen to be named. VRML has the beginings of an Object Semantic, but it
is not fully developed nor consistently enforced. For example, a Node is
referred to as an object when it is more specificly a class object used to
create object instances. And, while a Node is referred to as an object the
result of using a node is not thought of as an object (or at least this is
not explained directly in the spec) and DEF is not thought of as a way to
name an object but rather the way to define a named Node for the sole
purpose of "instancing". This severly limits its Object model. For example,
it is neither stated nor is it implied that DEF can be used to name
aggregate objects, regardless of whether it be an aggregate of Nodes, other
DEF's, Scene Graphs or any combination thereof. Further, a Scene Graph is
not specifically thought of as an object aggregation of Nodes.
Object Naming
=============
The ability to alias an object, much like the DEF keyword. A single object
or object aggregate can have any number of names, one name or no names. As I
mentioned in the last proposal, VRML has the seeds of this functionality but
it hasn't been entirely rationalized, generally applied, nor thoroughly defined.
Lexical scoping
===============
An object can be local to the (.wrl) or it can be globally visible and as
such be USE'd by other (.wrl) files. This becomes important when you apply
it to "Object Naming" or use it in object composition. For example, I may
benifit by using some smaller aggregate objects when composing larger
aggregates (such as a teapot). This is really great because I can use these
smaller objects to compose larger more complex objects like my Teapot. This
cuts down on the amount of Nodes I need to create and define for this. To
avoid going into great detail about this, lets just call it "modularity" and
say that it is usefull for "Node instance" reuse or "Aggregate Node
instance" reuse. However, if all objects are global, then I can have
collisions with names used in other (.wrl) files. If I define them to be
LOCAL, I will never have to worry about this. So, basically, I can make my
Teapot DEF global while the named objects that I used in composing it can
stay local. You can look at this as the difference between "local", "global"
or "class (module-wide)" variables that are used in languages like C\C++ or
Smalltalk.
Access
======
Very important, it is the ability to restrict access to objects or groups of
objects. Access can be restricted or given to groups or to the entire public
(workgrouping). Given that we adopt a consistent object semantic, an object
to restrict can be as granular as a single Node or as general as an entire
Scene Graph. This one is really important to a lot of people that don't want
the outside world to have the ability to change their Scene Graphs but is
also usefull for specifying which objects can be moved and where. There
should be multiple levels of access that are *not* mutually exclusive:
Editing
=======
Do you have access to edit the fields of an
object or parts of an Aggregate object?
Substitution
============
Do you have access to substitute your teapot
for the one the author specified?
Animation
=========
Do you have access to see the animation for
this object? (Good for many things besides
adult content.)
Movement
========
Can this object be moved around the scene?
(Good for making an ashtray moveable but
the desk it is placed on too heavy to move.)
Visibility
==========
Can you see this object? Good for hiding
private link that you only want people in
your company or division to have access to
such as "works in progress".
I believe all these things are essential for a really robust and general ODL
that allows users to interact with, protect, customize and compose scenes of
varying complexity. Additionally, I think they are simple and few enough to
add to the spec rather immeadiately without compromising its mission
statement or requirements. Lastly, I think they begin to give you and many
other the capabilities you want without having to create specific additions
to the spec that address each one directly. That is, these features and
constraints are not in the image of a particular taxonomy of functionality
but allow one to do pretty much anything (as I said before) from the
important to the absurd.
Robert