Entity Schema

Most current binary marshaling methods require either significant additional metadata with each marshaled request, or require that each participant be updated with new binary data each time the schema of any one entity changes. Neither of those are desirable properties in a real-time virtual world entity protocol. To solve this problem, we require that an entity does not change its schema during its instantiated lifetime during a simulation session. We can then send the entity schema once, before the entity data, and then use that schema as a key to how to decode the data. If an entity wants to undergo a "live" schema update (which in the end will be inevitable, because these systems will have to stay up 24/7), the entity itself can be removed from the session and then re-introduced with a new schema or schema version.

1. Master and Slave exchange entity telemetry
   1. Movement.
   2. Animation.
   3. Avatar chat might be described as telemetry.
   4. VoIP as telemetry?

Schema for an entity describes the properties and protocols of the entity. Schema may contain optional or variant subsections. The schema may implement a number of interfaces (which map to well defined properties), as well as custom extra properties. The property nids (numerical id) are not defined in the interface specification; they are specific to the entity schema in question. Versioning is of this schema for this provider, not for any "canonical" version of schema.

  <?xml version="1.0"?>
  <vwipschema target="entity" version="1.0" compatible="1.0">
    ''<!-- canonical URI name for the interface -->''
    <interface restriction="optional">uri</interface>
    <interface restriction="required">uri</interface>
    <required>
      <property nid="1">
        <semantic>labelname</semantic>
        <name>name</name>
        <type>string</type>
      </property>
      <switch>
        <property nid="2">
          <semantic>staticmesh</semantic>
          <name>mesh</name>
          <type href="uri">mesh</type>
        </property>
        <required>
          <property nid="3">
            <semantic>animatedmesh</semantic>
            <name>mesh</name>
            <type href="uri">mesh</type>
          </property>
          <property nid="5">
            <semantic>idleanimation</semantic>
            <name>idle</name>
            <type href="uri">animation</type>
          </property>

          <optional>
            <property nid="6">
              <semantic>walkanimation</semantic>
              <name>walk</name>
              <type href="uri">animation</type>
            </property>
          </optional>
        </required>
      </switch>
      <optional>
        <property nid="4">
          <semantic>idlesound</semantic>
          <name>breathingsound</name>
          <type href="uri">sound</type>
        </property>
      </optional>
    </required>
  </vwipschema>

Mesh data and animation data needs to be in some known format. Perhaps COLLADA or a low-overhead X3D profile can be used. The geometry per animated/simulated/moving entity won't be too complex to send as a single chunk (as opposed to terrain, which could conceivably be "the entire Earth.") For development purposes, I'm proposing BLAT as XML, transferred as bzip compressed text. It's possible for the receiving end to translate from the interchange format to a runtime optimized format.