This commentary is my (Mitra's) response to the latest draft of the Universal Avatars proposal that I've seen. It was last updated on 24th January in response to the 23rd January '97 draft. This commentary represents my own opinions, and not neccessarily those of the other editors of the Living Worlds Specification
Firstly, I should say that I'm supportive of the idea that it is neccessary to provide some standardisation of Avatar Semantics that allows Avatars to better interoperate, I believe the work done on the Universal Avatars mailing list is important to this.
However -
I've split my comments into three sections
If their is interest from the UA editors, then I'll make a proposal for alternative syntax that is more closely in tune with VRML2.0 and Living Worlds.
Avatar Context: Its unclear to me how usefull a concept this is, my guess is that people will choose different avatars in the same context, as often as they switch them between contexts, for example do you ALWAYS wear the same clothes to a party? Instead, I would see a user being prompted for an avatar and selecting between a set that they had previously constructed, and maybe a set supplied with the world.
A lot of things are fuzzy/un-defined, for example the precise semantics of "name, location, interests etc" mentioned as being required in the User Profile.
Why require a "an anonymous remailing mailto: tag that would link to the avatar management company so that requests for contact can be mediated by the company or the user's mailbot. " instead, just require an email address, if the user wants they can have the mail filter through a "avatar management company", or have mail agents or other To-Be-Determined innovations. Anyway, before this can be of use, the precise semantics and syntax of such email will need specifying.
The requirement for multiple avatars based on different systems doesn't make sense, and contradicts the statement about it being based on VRML2.0, in particular the section at the top of "Part 2: Models and Behaviors" .
The semantics of establishing a framework for naming behaviors makes lots of sense, but the syntax of linking them with behaviors, and searching for .class files doesn't work well with VRML - see below.
The area of Trust and Transactions is a very important area to specify, potentially one of the biggest contributions Universal Avatars could offer, however punting it to the third draft makes a number of other sections fairly meaningless.
Similarly, the area of Communications is a valuable one, however it isn't addressed here. Living Worlds contains the syntax to communicate these concepts, but had been waiting on Universal Avatars to define the semantics. This has been punted to the third draft.
"Client (Browser): This is the client side of the Universal Avatars specification. Typically, it will be the client side of a product like Worlds' AlphaWorlds or Chaco's Pueblo." If its VRML2, then it should be viewable on *ANY* VRML2.0 browser, the Avatar and/or World should carry enough code to ensure this. An enhanced browser can always implement certain extension nodes natively for performance reasons.
If the goal is to run in any VRML2.0 browser, then the spec is going to have to get a lot more detailed about things like this!
AvatarBehavior as link to a class file is not VRML2.0, VRML2.0 has a means to do this, called Script nodes. In Living Worlds we match between Script nodes and specific behaviors by the EventHandler nodes, which provides the neccessary syntax.
Intransitive behaviors: "Alice decides to make her avatar smile, so she either hits the smile button on her browser if it has one, or she types "behave: smile". Fred is hitting on Alice, and his browser receives that text. His browser looks to its local cache to see if it knows about Alice's smile behavior. If so, it just applies that behavior to her avatar. If not, it goes to the URL where Alice's avatar came from and searches in the same place for a smile behavior (http://avatar.com/user3211/vrml2/behaviors/smile.class)"
This is not close to VRML2.0 at all, in VRML2.0 the smile Script node is part of Alice's avatar, and if the behavior is complex, it can refer to a URL (anywhere) with the neccessary .class file. If Alice's avatar appears on Fred's browser, then LivingWorlds provides the mechanism (through its shared state) to communicate this change to Fred's browser, where the behavior will get executed locally in standard VRML2.0 fashion.
The spec says "First, we believe that trying to contain all behaviors within a single avatar data structure will require too much data to be transmitted." VRML2 already has mechanisms to handle this, the Script node can either contain the code if its small, or refer to a URL for the code if its large.
Transitive behaviors: "Our proposal is to create a methodology that integrates the current proposal for intransitive behaviors to use local server querying" What does this mean?
Since currently this doesn't match the rest of the proposal, (presumably this is what is meant by "This section is subject to massive rewriting") I'll save comments for later ....
Complementary Efforts: Living Worlds: "The portable VRML API of Living Worlds represents passive behaviors, and the unspecified proprietary APIs support interacting behaviors. A content developer can rely on Living Worlds to support interacting behaviors, but must build or license a proprietary multi-user API and server. "
This is not quite correct, the portable VRML API represents interactive behaviors, content developers have to assume that a world has incorporated ANY of the available multi-user technologies that support Living Worlds. The content developer does NOT have to program to proprietrary API's that is half the point of LW.