Subject: Re: [mmox] Proposal for small enhancement in the LLSD draft

From: Cenji Neutra <[email-masked]>
Date: Wed, 11 Feb 2009 11:24:13 -0500

Morgaine, I'm not sure I agree with your statement that "LLSD is an
Abstract Data Type specification", but perhaps I'm mistaken (not being
100% familiar with all the details of LLSD).  It appears to me that
LLSD is actually just an abstract syntax to represent data structured
in a specific way (the concrete syntax being its rendering in XML,
etc).  The structure itself is almost identical to that represented by
many other formats (e.g. JSON, IFF etc).  To my mind, an ADT defines a
both data, a set of constraints over that data and a set of operations
to transform the data that maintain the constraints (for example, a
list, queue, binary tree etc).

Perhaps xxSD doesn't belong in any MMOX standard at all, except as
being referenced as a preferred (or maintained) format for message
exchange in some VW-specific protocols the standard defines.  In that
case it may need to be standardized elsewhere (though I'm not sure it
adds sufficient additional benefits over its concrete serializations
in XML or JSON to warrant that).

Another possibility is that the MMOX standard doesn't mention xxSD at
all, but simply defines a set of alternative serializations for
messages (e.g. XML, JSON) that are constrained in such a way that they
just happen to be valid serializations of LLSD.

-Cenji (aka David).

The abstract data structure represented by LLSD is identical to that
represented by many other similar formats (e.g. JSON).  I would
characterize LLSD

> Date: Wed, 11 Feb 2009 14:44:19 +0000
> From: Morgaine Dinova <[email-masked]>
> Subject: Re: [mmox] Proposal for small enhancement in the LLSD draft
> To: Catherine Pfeffer <[email-masked]>
> Cc: [email-masked]
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Catherine, some of the "omissions" you mention actually reflect a desirable
> property of specifications:  Separation of Concerns.  Every time that a
> document becomes more strongly associated with one problem domain, the less
> useful it becomes in others.  If you employ generic formats then you can
> employ generic tools instead of having to create your own tools specific to
> your domain --- a great benefit.
>
> LLSD is an Abstract Data Type specification, but an ADT is not a protocol so
> you would not expect an ADT spec to discuss negotiation of serialization
> formats --- that belongs in the negotiation section of a wire protocol
> document.  And while Virtual Worlds will make use of specific ADT structures
> and map their VW data onto them, the VW is merely a SPECIFIC USER of
> structures defined by the ADT, not an exclusive definer of the ADT as that
> would be leaking VW concepts into the ADT spec.  (ADTs are "Abstract" by
> design and intent for reasons already mentioned.)
>
> In addition, Separation of Concerns is very strongly related to the idea of
> Decoupling which is so central to taming software engineering difficulties.
> If two documents describe different aspects of a system then you are quite
> likely to be able to change one without changing the other, which is much
> less likely if they are intertwined.  This benefit of separation doesn't end
> with the documents either, but carries over to the corresponding
> implementations as well.  Decoupling is A Good Thing.
>
> On the issue of "preferred serialization", this doesn't really hold together
> when you look at what it implies.  If a system offers two alternative
> serializations then they need to be equivalent in all important respects or
> they're not actually alternatives at all.  If they are true alternatives
> then this means that the system has implemented both fully, so why then
> would the spec express a preference?
>
> Which one is better is entirely dependent on the quality of individual
> implementations.  For example, both XML and JSON implementations are
> available with a very broad spectrum of performances, and therefore
> declaring a preference for JSON as "usually" faster than XML could in
> practice be quite wrong.  If you're going to offer multiple serializations
> then "ranking" them should not be prejudged.
>
> Morgaine.
>

---

From: Morgaine Dinova <[email-masked]>
Date: Thu, 12 Feb 2009 05:21:33 +0000

> in XML or JSON to warrant that).

And what you say reflects reality too --- LLSD is an independent data types
specification that isn't tied to VW use at all, so it doesn't fall naturally
into MMOX's native domain anyway.  We are mere USERS of such a spec, in the
same way that we will be mere users of many other RFCs and Internet
standards.

This is why LLSD as a milestone was omitted from the latest version of the
MMOX draft charter.  It's an LL milestone, not a MMOX one, and as Infinity
rightly pointed out, MMOX efforts are better spent dealing with VW concerns
rather than with abstract data type specifications.

Of course, if we find that an LL-published LLSD RFC is not adequate for our
needs then we will be making a modified/extended specification (or use
something different entirely) as a MMOX deliverable too, but nobody has
suggested a serious counter-proposal to using LLSD yet.

Morgaine.