RE: DOQ

["Crispen, Bob" <Robert.Crispen@HSV.Boeing.com>]

> Theresa-Marie Rhyne[SMTP:trhyne@vislab.epa.gov] sez:
> 
> "In view of this and comments made by others may i propose that we
> make a move
> to get this implemented." -- from Neil (see attachment below)
> 
> perhaps we need someone from the VRML community, perhaps a VRB member,
> to tell us how to make Neil's notion happen ?
> 
Sure.  There are two kinds of WG products called
out at http://www.vrml.org/WorkingGroups/process.html
-- Recommended Practices and Standards.
A Standard represents either a correction or an
addition to the VRML spec, and it can be added
to the existing IS or can be deferred to the next
revision of the standard.

A Recommended Practice, on the other hand,
doesn't require an addition to or modification of
the functionality of VRML, but rather represents
(a) something that world builders can do to
help achieve a particular purpose (this would
include the use of tools we might create), or
(b) something that VRML modeler builders can
do to help achieve a particular purpose.

Depending (mostly) on what this WG wants, the
Recommended Practice can be issued as a
separate Part to the standard or it can simply be
published as a Consortium document.

Taking the small question first, a new data type
seems to me to require an addition to the spec
(and from here on is personal opinion).

So what we (geovrml) can do is prepare an email
letter saying "VRML needs a DoubleCoordinate type"
and send it off to the VRB.  And we (the VRB) will
promptly send back a reply "No it doesn't", and
that takes care of that!

Or we (geovrml) can get a couple of us to prepare a
paper which will be read at VRML 99 supporting
the new type.  There will be applause from the
crowd and the authors will have a new notch in
their CVs, and nothing will happen.

Or, and this might actually work, we can use the
extensibility of VRML (e.g., EXTERNPROTOs)
and a couple of conventions about data typing
(using MFInt32 and assuming network byte
ordering -- big Endian -- are very popular ways to
begin) and prepare a package of VRML extensions
for geoscientists, demonstrating their usefulness
in principle.

If we (geovrml) begin with an analysis of requirements
and then turn those requirements into design and
demonstration of implementation, we might be
even better off when we (the VRB) look at the
results.

I realize this reply was a little smart-alecky, but
I think we need to scope out a big picture rather
than proceeding piecemeal if we're going to have
much success.  In other words, "Here's a
DoubleCoordinate node and here's a demonstration
of what you do with it" and so on.  My guess is
that we'll have some tools we develop or find,
some Recommended Practice things, and some
Standard things as parts of the package.

Just an opinion, obviously.

Bob Crispen
bob.crispen@boeing.com