Subject: [mmox] Entity model

From: Heiner Wolf <[email-masked]>
Date: Thu, 5 Mar 2009 17:19:20 +0100

Hi,

reading proposals and statements I stumble upon different models,
which people have in mind when they write their arguments. It could be
useful to discuss these models in order to define a common model in a
requirements RFC later.

There may be clients, servers, services, simulators, components,
objects, avatars, renderers, assets, and much more.

Which ones are we talking about?
What are they exactly?
Which do communicate at all?
Which communication would an MMOX wire protocol define?

To start things, I propose this MMOX 4-layer model:

display (UI and graphics)
   |
renderer (scene interpretation)
   |
simulator (scene model, script execution)
   |
services (assets, chat, presence, authentication, payment, etc.)

This model comes in various configurations:

1. Some worlds split the simulator, let the client simulate but check
the simulation at a trusted server, so the client-server communication
is inside the simulator (e.g. Games like WoW).

2. Some worlds simulate on a server grid and forward scene changes to
the renderer, so the client-server communication is between simulator
and renderer (please forgive me if I only mention SL here, there are
many more).

3. Some worlds have display, renderer, simulator in one client program
and services are rather lightweight, so the client-server
communication is between simulator and services (e.g. Weblin,
Metaplace?, IMVU?).

4. There will also be systems where renderer, simulator, and services
are in the cloud and the display is rather thin. The client-server
separation is between display and renderer (I hear of about the Fusion
Render Cloud and Cell render farms).

This clearly shows, that there is no point talking about a client
which does certain things and a server. The model should be a
functional decomposition, not about where the entities are located in
the network.

It might be interesting to check, if we can fit all the systems we
care about into configurations of this 4-layer model. There are
hundreds (see http://www.kzero.co.uk/blog/?page_id=2563 and
http://www.associationofvirtualworlds.com/publishing_blue_book.php). I
bet we will add more configurations in the process. If we fit them in,
then the model has a chance, if not then we find a different model.

Best
-- 
Dr. Heiner Wolf
[email-masked]
www.wolfspelz.de
www.virtual-presence.org

---

From: "Mark P. McCahill" <[email-masked]>
Date: Thu, 5 Mar 2009 15:12:35 -0500

I'm not sure that Croquet fits comfortably into the 4 listed models  
listed
below so I would add a 5th category:

5.) Some worlds run bit-identical replicated simulations across peers
and work by sending temporally ordered messages across the peers
to synchronize the simulation computation  (Croquet)

> communication is between simulator and services (e.g. Weblin,

my understanding is that Metaplace runs the Lua scripts that give  
objects their
behaviors on a traditional MMO server (and so can protect scripts from  
copying),
but runs the rendering using the flash engine embedded in a web page.

> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox

---

From: Dan Olivares <[email-masked]>
Date: Thu, 5 Mar 2009 19:07:34 -0500

Hmm,

I guess, I would also fit physics into a roll of a simulator along
with scripting.   Some implementations will not use physics, some will
not use scripting.

Does this distinction also require us to look at the use of the word,
Simulator,  a bit more closely?    In the context that it's used
above, it sounds more like a 'coordinating server' or a 'shared scene
graph server', then a 'simulator'.   The idea of a Simulator, to me,
means it's simulating /something/, be that scripting..  or some kind
of world model(physics?).    Microsoft Flight Simulator, for example,
 is a simulator on a local computer.  SimCity..   simulates the jobs
(and rewards) of running a city.  RollerCoaster Tycoon simulates
managing an amusement park.  OLIVE simulates the objects on each of
the clients and sends the telemetry to a 'coordinating server'..
(Correct me if I'm wrong, Jon).   SecondLifeGrid simulates (using
physics, scripts, and interactions) objects on the same host that acts
as the coordinating server.

Maybe my thoughts here are nit picky and it doesn't really matter. :D

Sincerely

Daniel Olivares

On Thu, Mar 5, 2009 at 3:12 PM, Mark P. McCahill <[email-masked]> wrote:
> I'm not sure that Croquet fits comfortably into the 4 listed models listed
> my understanding is that Metaplace runs the Lua scripts that give objects
> their

---

From: Heiner Wolf <[email-masked]>
Date: Fri, 6 Mar 2009 01:12:41 +0100

> to synchronize the simulation computation  (Croquet)

Sounds very similar to my configuration 3. with the addition, that the
simulators synchronize. I do not know if you would call "services are
rather lightweight" in Croquet though. Maybe I should delete this
wording.

> but runs the rendering using the flash engine embedded in a web page.

Very likely. So, Metaplace would be similar to my configuration 1.
where the simulator is split up between client and server.

-- 
Dr. Heiner Wolf
[email-masked]
www.wolfspelz.de
www.virtual-presence.org

---

From: Jon Watte <[email-masked]>
Date: Thu, 05 Mar 2009 16:19:14 -0800

> as the coordinating server.

OLIVE simulates on the server, and also simulates in sync on the 
clients. In fact, the "authoritative" or "zero latency" state is on the 
server, so the clients can't cheat. This is not dis-similar to the "RTS" 
model (check the article "1,500 archers on a 28,800 modem" on gamasutra 
for a thorough reference) but with variations to suit an open-ended 
world and deal with lossy transmission.

I think you're right on the rest of the observation -- if there is a 
server that responds to, generates or routes object movement 
information, it doesn't need to do simulation. World of Warcraft, for 
example, doesn't do physical simulation on the server as far as I know; 
it only checks the actual RPG rule set.

Perhaps call it a "virtual world router" as a better term for the 
particular role we're talking about there. FYI: OLIVE splits the output 
routing and interest management into a "view service," while putting 
simulation and input injection onto a "simulation host" service, but 
what we're talking about as visible externally is the aggregate of those 
two services, I believe.

I'm starting to feel the inadequacy of ASCII here -- I'm wanting to 
crack out Inkscape and include some SVG... I'm sure if we all saw a 
diagram, we'd see what the similarities of most of the systems actually 
are at the coarse level.

Sincerely,

jw

---

From: Heiner Wolf <[email-masked]>
Date: Fri, 6 Mar 2009 01:40:41 +0100

> with scripting.   Some implementations will not use physics, some will

Yes, I would put physics along with scripting. Both in the simulator.
Which does not mean, that both are in the same program, if the
simulation is split between client and server.

> as the coordinating server.

I totally agree. The simulator seems to be the central component for
our discussion. I get the impression, that we should enable the
simulators of different vendors to instantiate and simulate foreign
avatars (and items), but that we should not define how the simulator
feeds the scene description to the renderer.

> Maybe my thoughts here are nit picky and it doesn't really matter. :D

I am very grateful. It helps a lot to understand different models.

Best
hw
-- 
Dr. Heiner Wolf
[email-masked]
www.wolfspelz.de
www.virtual-presence.org

---

From: Jon Watte <[email-masked]>
Date: Thu, 05 Mar 2009 16:54:08 -0800

> feeds the scene description to the renderer.

If you read the LESS proposal carefully, you don't actually get a copy 
of "the avatar" -- you get a representation of what the avatar is doing 
in its originating simulation, such that your objects can react to it, 
and you can forward it to your clients/users/viewers.
Trying to instantiate the authoritative, user-driven "master" copy of 
some kind of object from a foreign source isn't really practical, 
because of the extremely tight coupling to an extremely large number of 
subsystems needed (which I call the "execution environment" -- UI, 
script, physics, messaging, etc).

Sincerely,

jw

---

From: "Mystical Demina" <[email-masked]>
Date: Thu, 5 Mar 2009 19:54:25 -0500

When you look at existing interoperability solutions they happen at
different levels.  For instance different companies have different network
hardware devices but they are still able to move TCP/IP packets.  Different
computers run different operating systems but they are able to exchange data
through web services using things like XML, SOAP with their web services.
Basically for any two or more systems to be interoperable there has to be
and end point that defines the protocol, transport and message format for
data to be exchanged.  But the good thing is not everyone has to define the
same endpoints.  Some companies may choose to use the same protocol over XML
but others may decide to do it with a binary format. So I think it is a good
direction to start talking about the stack that virtual worlds will
interoperate on but keep in mind that there is a huge investment in
different technologies the more flexibility we have in defining the
endpoints the easier it will be for companies to participate.

I can understand at some level in the stack there will be a distinction of
having to call something a client and a server, but is it better to call it
a provider and a consumer?  Or is it better to define the concept of an
interface and any endpoint that supports the methods of the interface can
behave like a client or a server.  Do all clients have to run on a PC or
could a server be talking to another server and acting as a client.  When
you look at HTTP it talks in the terms of the client and a server but
nothing says the client is a browser, it is just someone that can open a
TCP/IP connect and pass HTTP formatted message over TELNET session.
 
So what I what I am thinking is that there is a more fundamental abstraction
that that all of these relationships can be decomposed into and from the
fundamental building blocks different players in the virtual world supply
chain can choose to implement the pieces that they need to accomplish there
goals.

I am thinking these most fundamental building blocks are based on how we
define what a virtual world is and what the minimum capability to be
interoperable are and then how we define extensions that can be built upon
these atomic level objects or services.  To me I see two things, coordinate
systems and objects.

Through specification of a coordinate system we can define absolute and
relative relations of objects.  We may assume that this is easy but as any
one knows that uses multiple 3D packages not all z,y,z coordinate systems
are defined the same.  Just reading this we can see that the specification
needs to be simple but extensible to allow different coordinate systems to
work together.  Not all units of measure are the same.  Often bringing in
objects from different packages requires and understanding of the coordinate
system and the scale the originating object came from.  What about time.
How is time included in the coordinate system?  Most virtual worlds are in
current time.  Not to confuse with the concept of a stream of frames and
time although I think they are related.  I can see scenarios where the
virtual world presented to me is based on the time I specify for instance
looking at next weeks production plan simulation, or planning different
stages of building a sky scraper in which we need to review some design
considerations.  Is time part of the camera? Or part of the coordinate
system.  How will it be defined?  Also rate of time passing could be part of
the coordinate system that is being used

Here is some interesting reading
http://en.wikipedia.org/wiki/Coordinate_system

Through the specification of an object I think we will find solutions for
many of the issues that are being discusses.  I think existing object
specifications using in object oriented programming offer a foundation for
this.  Concepts life cycle of the object, who owns the object, how is
encapsulation done, how method and method passing done is, polymorphism.
Here is a good reference to kind of functionality I can see being
foundational.  
http://en.wikipedia.org/wiki/Object_oriented

And as such through the concept of emergence we can them build complex
concepts such as teleporting in an interoperable way.
http://en.wikipedia.org/wiki/Emergence

As an example if we take teleporting and abstract it into coordinate system
specification and object specification it could look something like this.

Object A exposes a public endpoint that supports the identity interface.
The identity interface is the interface that all objects expose.

Object B finds Object A's identity endpoint on a website and opens the
endpoint and request its identity.  

Object B then sees if Object A supports a Create Object interface.

Object B contacts the Object A's Create Object interface and sends and
Create Object request.

Object A creates this new Object C in its space and returns the identity
interface to Object B.

Object A assigns Object C's Owner Interface Object A's Identity.

Object C requests its shape from Object A and object A streams the shape
type and specifications.

Object B then interfaces with Object C's Change Location interface to move
the object in Object C's coordinate space.

Object C has a script in LSL syntax so ask Object A for an Execute Script
permission.

Object A grants this permissions and provides the interface to the script
engine.

Object C enables the script.

Object C's script ask the script interface to execute an animation and is
granted permissions

Object C's animation starts and it jumps for joy.

This isn't meant to be a rigorous description but an example of my thoughts
on how to abstract something like teleporting into two completely different
architectures and technologies.

I purposely didn't refer to clients and servers, Object B could be another
virtual world, a client program or even some non related service that has a
relationship with a virtual world.  Object C could be an avatar, a scene or
a complete virtual world although virtual worlds don't jump for joy.  Also I
purposely did not specify the transport layer or the message formats but
they would have to be agreed on but could be different from company to
company depending on their network and technologies they implemented for
their domain of relationships.

I just wanted to support your email and add a twist to it and some thoughts.

Regards,
Kevin Tweedy
SL: Mystical Demina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Heiner Wolf
Sent: Thursday, March 05, 2009 11:19 AM
To: [email-masked]
Subject: [mmox] Entity model

Hi,

Best

---

From: Kajikawa Jeremy <[email-masked]>
Date: Fri, 06 Mar 2009 13:05:43 +0900

That is probably also the basis why some of my messages seem
  to be more braindump than others...
Im also wanting for allowing implimentations to only need a barebones
  when the option for interop is chosen...

maybe I am being too simpleminded for this group?

Jeremy

---

From: Morgaine <[email-masked]>
Date: Fri, 6 Mar 2009 05:18:29 +0000

On Fri, Mar 6, 2009 at 12:07 AM, Dan Olivares <[email-masked]> wrote:

> with scripting.   Some implementations will not use physics, some will not
> use scripting.
>
> Simulator,  a bit more closely?

I would argue that we should not use the word Simulator at all, since it's
none of our business (as protocol purveyors) how or where worlds do their
simulation.  Our protocol is expected to operate between endpoints, and
those endpoints denote general services, not specific implementation
concepts.

Notice that while SL uses simulators as discrete simulation processes for
regions within servers, OGP Base doesn't refer to simulators at all, because
that would be technology-specific.

The Region Domain of OGP is a *service*, and in principle needn't expose
individual regions at all since exposing them is a policy decision.  Even
worse, exposing regions as single processes is a design choice that can
severely hamper scalability, so one should not go there.

Once we get into protocol analysis, I'll be taking a close look at how OGP
handles access to regions, because potentially that could make OGP
non-viable for scalable worlds.  Needless to say, enshrining SL's region
non-scalability into the protocol is not our goal.

Morgaine.

---

From: Heiner Wolf <[email-masked]>
Date: Fri, 6 Mar 2009 09:24:38 +0100

Hi,

I totally agree. My term "simulator" does not mean a process or a
host. It rather means the simulation service of a system. But I can
not call everything a service, so _the_ "simulator" in the model
comprises all components which do simulation in a system be it a
process, a client, a server, components in both client and server, or
a grid.

Many systems do not have something called a "simulator" and especially
if the scene is created and maintained by the client, with or without
syncing. They often call it just "the client". But it seems that all
systems do simulation one way or another, hence the term simulator in
the model.

Best
hw

On Fri, Mar 6, 2009 at 6:18 AM, Morgaine <[email-masked]> wrote:
> The Region Domain of OGP is a service, and in principle needn't expose

-- 
Dr. Heiner Wolf
[email-masked]
www.wolfspelz.de
www.virtual-presence.org

---

From: Morgaine <[email-masked]>
Date: Fri, 6 Mar 2009 09:25:30 +0000

On Fri, Mar 6, 2009 at 12:54 AM, Mystical Demina
<[email-masked]>wrote:

> ... although virtual worlds don't jump for joy.
>

Don't be so sure about that.  It's bound to be coming. \o/  ;-)

Great post though.  And yes, many OO concepts are relevant to the components
parts of VWs, which is not surprising since VW entities share many
properties with those in the physical world.  That doesn't necessarily imply
OOP at the API level though, because unless one is very careful or highly
abstract that can lead to language-specificity.

Morgaine.

---

From: Lawson English <[email-masked]>
Date: Fri, 06 Mar 2009 02:37:52 -0700

Morgaine wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>  
>
> Great post though.  And yes, many OO concepts are relevant to the 
> components parts of VWs, which is not surprising since VW entities 
> share many properties with those in the physical world.  That doesn't 
> necessarily imply OOP at the API level though, because unless one is 
> very careful or highly abstract that can lead to language-specificity.
>

Since the original OOP language was called "Simula" it's not exactly 
surprising that OOP and VW are often a close fit.

And, its not a worry about language specificity that concerns me so much 
as inflexible object models that freeze details that should be left 
undefined while defining external specs for programmer convenience. Even 
if SL avatars weren't ready to handle posable fingers due to 
rendering/bandwidth constraints, that was no excuse to leave finger 
posing out of the avatar spec, for example.

L

---

From: Morgaine <[email-masked]>
Date: Fri, 6 Mar 2009 09:55:03 +0000

On Fri, Mar 6, 2009 at 9:37 AM, Lawson English <[email-masked]> wrote:

>
> And, its not a worry about language specificity that concerns me so much as
> inflexible object models that freeze details that should be left undefined
> while defining external specs for programmer convenience. Even if SL avatars
> weren't ready to handle posable fingers due to rendering/bandwidth
> constraints, that was no excuse to leave finger posing out of the avatar
> spec, for example.
>

Well said Lawson.

Building in extensibility will undoubtedly be a major part of our work, but
it won't be unopposed because it requires work and entails cost.

Finding a good balance isn't entirely objective, but some things are more
reasonable than others, and providing extensibility for major features of
human expression definitely falls right in the centre of the reasonable set.

As always, our protocol should provide mechanism and not define policy.  If
a VW wishes not to handle finger posing owing to cost or technology
constraints, that is their choice, but it should not dictate the choice of
others.

Morgaine.

On Fri, Mar 6, 2009 at 9:37 AM, Lawson English <[email-masked]> wrote:

> Morgaine wrote:
>
>> On Fri, Mar 6, 2009 at 12:54 AM, Mystical Demina <
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
>> components parts of VWs, which is not surprising since VW entities share
>> many properties with those in the physical world.  That doesn't necessarily
>> imply OOP at the API level though, because unless one is very careful or
>> highly abstract that can lead to language-specificity.
>>
>>
> And, its not a worry about language specificity that concerns me so much as
> inflexible object models that freeze details that should be left undefined
> while defining external specs for programmer convenience. Even if SL avatars
> weren't ready to handle posable fingers due to rendering/bandwidth
> constraints, that was no excuse to leave finger posing out of the avatar
> spec, for example.
>
>
> L
>
>
>

---

From: Kajikawa Jeremy <[email-masked]>
Date: Fri, 06 Mar 2009 19:03:51 +0900

Thats why I mentioned the requirement for anything transferable to have
 an indefinite list of attributes,

 <OBJECT name="Freija Yoshikawa">
  <ATTR name="UUID" encode="utf8:string"
>0000-0000-0000-0000-0000</ATTR>
  <ATTR name="<key>" encode="utf8:string" >utf8-string-value</ATTR>
  <ATTR name="multi-key" encode="utf8:strkeys">
   key:string
   key:string
   key:string
  </ATTR>
  <ATTR name="Avatar-Mesh" size="" encode="" >
   datablock of encoding type
  </ATTR>
  <ATTR name="Avatar-Prim" size="" encode="" >
   datablock of encoding type
  </ATTR>
 </OBJECT>

 I consider the above "open ended" in that additional components of the
system stack
  or an editor can "add" to the <ATTR /> markers present and each
<ATTR /> is only
  a part of the complex object,  where attribute names are what are
declared along
  with a permitted data type and encoding for the attribute,
  (an image may be encoded many ways and be transported in most of them)

  I am considering the divergence of systems already existing by
allowing properties
  of each to be "neutral encoded" on non-origin systems when
transported,
  and for the content-creator to be enabled when logging into each
system to edit
  the materials on the target systems when shared to allow for a "best
appearance"
  to not be "dulled" or "broken" when crossing VW boundaries.

 since I only define for an "object" having "attributes" and each system
or systems
  sharing the object define the attribute requirements and encodings.

 I am using the above to display in an XML style 

 I am not advocating for or against any technology but only making this
suggestion
  towards a completely neutral packetization allowing further extensions
indefinitely.

 I also hope this is beneficial towards selecting an acceptable
on-the-wire formatting.

Please consider this suggestion,
  Jeremy

---

From: Christian Scholz <[email-masked]>
Date: Fri, 06 Mar 2009 12:30:11 +0100

Great discussion here! :-)

> services (assets, chat, presence, authentication, payment, etc.)

I personally would add "Service Discovery" even below that. So that 
every component can find out about what services the other components 
support (and where those services are).

And apparently there are many different ways to look at the problem and 
how to group services and data formats. And as "services" above is 
mainly 2D related stuff which is also useful in a non-VW scenario maybe 
this can be called a bit differently than just "services". I just don't 
know what ;-) But those services seem to be very much related to the 
user so maybe "user services" or "social services" (but 
authentication/authorization does not really fit in there then).

As the term "simulator" was discussed (and some others) maybe we can 
also try to collect what components existing virtual worlds actually 
have and try to find common terms for it. It might be that those terms 
are used in existing worlds but we might then refer to e.g. "SL simulators".

I am also interested in a high level picture of how the different worlds 
actually work. I know mainly how SL works (although not on the detailed 
level opensim devs know it) and I know a little bit about weblin from 
what Heiner once explained to me. But for the rest I have not really a 
clue. As I guess that this will be true for many people here (and 
newcomers to the list) maybe we can also collect some descriptions 
somewhere.

-- Christian

-- 
Christian Scholz
Blog: http://mrtopf.de/blog
Company: http://comlounge.net
Podcasts: http://datawithoutborders.net, http://openweb-podcast.de

---

From: Christian Scholz <[email-masked]>
Date: Fri, 06 Mar 2009 15:00:49 +0100

>  an indefinite list of attributes,

As long as nobody redefines an attribute.
Maybe it should be different sets of attributes which are grouped into
specifications. You can then have some base avatar set and extensions
which e.g. provide finger posing.

But again I think it's premature to think about it before we know what
might need to be extensible.

-- Christian

-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge                                   blog: http://mrtopf.de/blog
Luetticher Strasse 10                                    Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0                           E-Mail [email-masked]
Fax: +49 241 979 00 850                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)

---

From: Lawson English <[email-masked]>
Date: Fri, 06 Mar 2009 07:44:50 -0700

>   <ATTR name="UUID" encode="utf8:string"

MPEG-21 defines avatar animations with a mesh at the start. There's no 
reason why we couldn't streamline that
by predefining various "standard" VW meshes but with the option to 
define a new mesh. More difficult will be defining
what a non-humanoid avatar might be like. MPEG-21 vaguely refers to 
extensions to H-ANIM but doesn't go
into any details. It would be nice to find out what their thoughts are 
and see if its sufficient or if we should extend
and/or modify the upcoming MPEG-21 spec in some way.

Lawson

---

From: Morgaine <[email-masked]>
Date: Fri, 6 Mar 2009 14:48:37 +0000

Indeed Christian.

Note my little list of metadata tags 1/3rd of the way down in my post on
Permissions<http://www.ietf.org/mail-archive/web/mmox/current/msg00526.html>.
 Each of the important attributes should have such a list, not just
permissions.  The cost is minimal --- a null field (or even zero-length on
the wire) for an empty attribute.

Given that we are trying to do this properly for the benefit of Mankind
(which sounds grandiose but actually reflects official IETF principles
extremely closely), I think that this completely unnoticeable overhead is,
well, unnoticeable, and required. ;-)

Morgaine.

---

From: "Mystical Demina" <[email-masked]>
Date: Fri, 6 Mar 2009 09:58:23 -0500

This works by streaming the actual changes in the vertices?  Or is it
skeleton based?

Why you feel it is more difficult to define a non-humanoid avatar?

I see if the skeleton changes the animations need to be compatible with them
so will be issues of what animations work with what objects.

Thanks,
Kevin Tweedy
SL: Mystical Demina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lawson English
Sent: Friday, March 06, 2009 9:45 AM
To: Kajikawa Jeremy
Cc: [email-masked]
Subject: Re: [mmox] Entity transfer, 2-layer extensible stacking formatted
data.

Lawson

---

From: Heiner Wolf <[email-masked]>
Date: Fri, 6 Mar 2009 16:28:08 +0100

Hi,

just to check my understanding of your post. Could it be that your XML is
very similar to
http://www.ietf.org/proceedings/staging/draft-wolf-vp-identity-00.txt ?

The example in this draft is like:
<identity>
  <item id="avatar"
    contenttype="avatar"
    size="2579"
    order="1"
    src="http://avatar.foobar.com/astronaut.gif"
    digest="da03dc963a28b4dbccd28b3cad7a2177de41bad7"
    />
  <item id="properties"
    contenttype="properties"
    digest="cbe86cb69e979414d259e487ab500f138e42c6d7"
    mimetype="text/xml" >
      <![CDATA[<?xml version="1.0" encoding="UTF-8"?>
      <properties>
        <property name="Nickname" value="Tassadar"/>
        <property name="Gender" value="male"/>
      </properties>
      ]]>
    />
</identity>

Imagine you replace in your example
  <OBJECT> with <identity>
  <ATTR> with <item>
  name= with id= and contenttype=
  encode= with encoding=
and allow for external URLs in _addition_ to your embedded datablocks.
contenttype could freely chosen by implementations or by IANA (like your
name). Any mimetype could be used.

Your example in VP-Identity language would then be like:
<identity>
  <item id="UUID" contenttype="properties" encoding="plain">
    Nickname=Freija Yoshikawa
    key=string
    key=string
  </ATTR>
  <item id="UUID"
    contenttype="Avatar-Mesh" encoding="">
    datablock of encoding type
  </item>
  <item id="UUID"
    contenttype="Avatar-Prim" encoding="">
    datablock of encoding type
  </item>
</identity>

VP-Identity has no OBJECT-name. Instead it uses the URL as unique ID. But
thats a minor issue. Would that somehow fit?

Best
hw

-- 
Dr. Heiner Wolf
[email-masked]
www.wolfspelz.de
www.virtual-presence.org

---

From: Christian Scholz <[email-masked]>
Date: Fri, 06 Mar 2009 16:35:20 +0100

Heiner Wolf wrote:
> Hi,
> 
> just to check my understanding of your post. Could it be that your XML
> is very similar to

I wouldn't actually call this <identity> btw because IMHO the identity
should be more of the form of a URL or email address from which you then
can do service discovery to retrieve a service capable of returning a
representation of your avatar.
Or one might actually have multiple avatars/agents per identity which
all have their own appearance and maybe inventories.

-- Christian

> VP-Identity has no OBJECT-name. Instead it uses the URL as unique ID.
> But thats a minor issue. Would that somehow fit?
> 
> Best
> hw
> 
> On Fri, Mar 6, 2009 at 11:03 AM, Kajikawa Jeremy <[email-masked]
> <mailto:[email-masked]>> wrote:
>>> > <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>
> wrote:
>>> >
>>> >
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> www.wolfspelz.de <http://www.wolfspelz.de>
> www.virtual-presence.org <http://www.virtual-presence.org>
> 
> 
> ------------------------------------------------------------------------
>

---

From: Heiner Wolf <[email-masked]>
Date: Sat, 7 Mar 2009 11:43:38 +0100

> I wouldn't actually call this <identity> btw because IMHO the identity

Ah, yes, my question to Jeremy was more structure-wise, specifically
ignoring the tokens. I do not really care if it is called <identity> or
<OBJECT> if it does the same. I am trying to find out if the structure is
the same disregarding the names.

> representation of your avatar.

Agan, yes, the identity is identified by a URL (like OpenID). In case of VP
Identity the URL points to directly to data,that defines the avatar. No
service discovery here. I am not arguing what's "better". It just is that
way currently.

> all have their own appearance and maybe inventories.

If you want multiple avatars in one identity, then you would probaly derive
multiple VP Identity URLs from OpenID by attribute exchange. Each VP
Identity URL points to one avatar. Each avatar can carry data in multiple
formats.

Best
hw
-- 
Dr. Heiner Wolf
[email-masked]
www.wolfspelz.de
www.virtual-presence.org