Hmm. You're on to something, but... hmm. "Markup Language" denotes
some sort of high-level structural description of the scene is preferred
over precise details - exactly the reaons why writing an HTML file
by hand is a couple orders of magnitude easier than writing a Postscript
file by hand (though I know sick people who like to do that :) In
HTML, you don't say "Helvetica 11pt, adjusted 2 points to the right of
the margin and 50 points below the top margin..." you say "<H2>".
Now, it's possible that laying out a document is orders of magnitude
easier than laying out a scene, but it seems like being able to
specify "a room with two chairs and a table" is preferable to a list
of 400 polygons. Hmm. This is a Tough Problem. It wasn't too hard
to constrain document layout types to a dozen often-used tags and 2-dozen
moderately-used tags and 100 rarely-used tags, but maybe this is just
something you can't do in an almost purely visual environment like VRML
would describe. Maybe it's because there's no baseline semantics to
what people will want to represent with VRML, in the same way that
headings and emphasized text are semantic constructs of an HTML file.
Perhaps the best we can do is make sure every object in a scene, as
well as, say, lights and surfaces and collections of objects, can be
given a unique name within the scene. Then, with a very advanced VRML
authoring tool, we'll be able to say "create a scene with a table and
two chairs" and it'll give us a full VRML file, or a small file
describing the placement of a table object and two chair objects, and
then referencing the table object and chair object files.
> As for standards, I'd suggest that the real issue isn't creating a
> central repository of "official" classes -- rather, we should have
> a scheme that allows us to identify *different* classes. The issue
> isn't whether the user has the "official" teapot, it's whether he
> has the same teapot (or a sufficiently similar one) as the one the
> scene designer had in mind. This implies that we want a system of
> nomenclature designed to uniquely identify each class. If the user
> already has the class called for, great; if not, he can pick it up
> from the serving site. Off the top of my head, a simple mechanism
> would combine the full net-id of the designer or the designing site,
> plus the name of the object and a numeric disambiguator; I'm sure
> that other, better nomenclatures could be found.
Yes, agreed. Maybe even something like a cross between NNTP and
nameservice, where the object names are like Message-ID's, and
they expire out of disuse after 2 months, and if they need to be
obtained but aren't in the local machine a search "up the tree" is
done until you get to some final registry where it's guaranteed to
exist (maybe even the machine in the ID itself).
On the other hand, that means a new MIME type, a new URL scheme,
and a new client-server protocol. Ewwww. Perhaps we can rely upon
HTTP cache technology to improve upon this sufficiently? For oft-
obtained objects it'll definitely improve efficiency, and not have
the "flooding" effect of NNTP. So, every VRML file that "inlines"
another object must guarantee it'll have that object (or references
an object at another site guaranteed to have it) so that people without
caches and CD-ROM's can see everything, but those with local caches
and CDROM's also win.
Brian