I think the short answer is: no.
That is, the language is intended to be orthogonal to this whole
issue. Just as HTML *can* be used in any of these environments, so
(probably) should VRML.
(As I've gotten fond of pointing out, this is making the possibly-
heroic assumption that we can get the URI standards to work
appropriately, so that we *can* ignore those issues. But that *is*
clearly the ideal.)
>Another conceptual trauma, even more basic: Are VRML spaces static, or
>dynamic? Obviously there is some dynamism in the use of a link, but does
>that mean that each link simply takes you to another static space? I
>think the answer is "No".
I'm assuming, based on what you say later, that you are basically
asking whether users have the ability to alter VRML scenes in a
permanent sort of way. That's a whole 'nother issue, and is also
probably orthogonal to the language issue. It's probably not
appropriate to this list, so I'll just toss out one observation:
this is a subset of the VRMUD question. A VRMUD is VRML + user-to-user
interaction + a dynamically changeable object set (probably with
behaviours). I've got opinions on how this *should* be implemented,
but I've posted them before, and it's really a bit off-topic...
>Do we need to limit VRML to the simple process of "marking up" a static
>scene? Should we then define another language for interaction and motion
>("what to do when the user does something"), to add the dynamism of an
>interactive environment?
I think that's what most of us had in mind, yes. Although it's not
clear whether we're talking about a language per se, an API for outside
programs to communicate through, or some hybrid of the two. VRML is
the scene-and-object description language; other things make it
dynamic. That other language/API also probably wants to be standardized,
but again, it's an orthogonal question...
>This leads me to my last question: Since the dynamic part of VRML is at
>the client, don't we now need yet another language and transport system
>for the servers to run which distributes the changes to the space that
>one user makes, to all the other users who are in that same (multi-user
>interactive) space? Do we need a VR Interaction Protocol (VRIP)?
In some fashion, probably, although I think the range of possibilities
is a lot broader than you're realizing. But again, it's outside the
actual VRML language-design issue; it's much more a VRMUD issue.
So -- have people signed up for the other VRML mailing lists yet?
Shall we take at least some of this discussion over there?
-- Justin
Feeling a bit guilty about helping to
sidetrack the discussion, and trying to
help get www-vrml back in focus again...
Random Quote du Jour:
"RULES (as near as I can figure) for AUSSIE FOOTBALL:
1) no full-auto weapons
2) you must give back any body parts after the game
3) injured or killed players may be replaced
4) oh, yeah... get the ball through the goals...."
-- Ioseph of Locksley and Olafr Thordarson