MMOX Live Object Description Schema specification
MMOX LODS Specification
Version 0.1, 2009-03-01
Jon Watte (jwatte@gmail.com)
The Live Entity State Stream Protocol requires object types to be described in schema, defined separately from the state stream protocol. This document describes the format of such schema. The role of schema is to subdivide functionality groups of a given object into separate interfaces (of which a given object may have more than one instance), and then defining the properties that can be reflected on an implementation of those interfaces. A peer subscribing to an object stream chooses which interfaces, and which properties within those interfaces, to receive reflected data on. This means that the recipient is guaranteed to always understand the data type of all data it receives.
Each object type being interchanged will use a separate schema. A schema is identified with a URI. The URI for the schema changes each time the schema version changes, so that there is a permanent relation between a given URI and the specific schema version. This allows cached schema copies to be stored with object data indefinitely.
The object schema references a vocabulary schema, which is also referenced by URI. It is desired that a session will use only one vocabulary schema, and all objects within the session will reference that same vocabulary schema, but because objects may come from many different sources, multiple vocabulary schemas may in fact be in effect for the same session.
Systems where each object is unique, and may have unique properties and capabilities, will define one object type schema per object. Meanwhile, the vocabulary schema allows common basics, including a description of the kinds of components that may make up an object, to be sent and parsed only once.
TODO
Version 0.1, 2009-03-01
Jon Watte (jwatte@gmail.com)
The Live Entity State Stream Protocol requires object types to be described in schema, defined separately from the state stream protocol. This document describes the format of such schema. The role of schema is to subdivide functionality groups of a given object into separate interfaces (of which a given object may have more than one instance), and then defining the properties that can be reflected on an implementation of those interfaces. A peer subscribing to an object stream chooses which interfaces, and which properties within those interfaces, to receive reflected data on. This means that the recipient is guaranteed to always understand the data type of all data it receives.
Each object type being interchanged will use a separate schema. A schema is identified with a URI. The URI for the schema changes each time the schema version changes, so that there is a permanent relation between a given URI and the specific schema version. This allows cached schema copies to be stored with object data indefinitely.
The object schema references a vocabulary schema, which is also referenced by URI. It is desired that a session will use only one vocabulary schema, and all objects within the session will reference that same vocabulary schema, but because objects may come from many different sources, multiple vocabulary schemas may in fact be in effect for the same session.
Systems where each object is unique, and may have unique properties and capabilities, will define one object type schema per object. Meanwhile, the vocabulary schema allows common basics, including a description of the kinds of components that may make up an object, to be sent and parsed only once.
Schema language description
TODO