Re: [mmox] LLSD and content schema

["Meadhbh Hamrick (Infinity)" <[e-mail]>]

On Feb 20, 2009, at 12:21 PM, Jon Watte wrote:

> Meadhbh Hamrick (Infinity) wrote:
>> * LLSD is implementable by mortals in a tractable amount of time  
>> and without the use of complicated third-party tools (ASN.1  
>> compilers, etc.)
>
> I don't see the LLSD interface compiler as any different in  
> conceptual complexity than an ASN.1 compiler. I did bring up the  
> question of ASN.1 before, and was told by you that you felt it was  
> "too buggy," which I think is not fair or accurate.

which LLSD compiler are you referring to? i wasn't aware that one was  
required or available.

> However, I believe ASN.1 and also LLSD have a problem that I'd like  
> to see addressed in a standard: they use implicit schema.
>
> If I want to send a piece of data from point A to point B, and the  
> points don't both exactly know what the data is, that's fine -- but,  
> in that case, you typically want to use something a little more open- 
> ended and more generally standardized, like XML. The benefit of XML  
> is that there are tons of tools that already support it (as there  
> are with ASN.1, btw); XML also allows well-formed documents to be  
> verified using XSD schema. If you need large binary blob support  
> (textures, etc), those can be included by reference uri. I think XML  
> is appropriate for those cases, and LLSD doesn't quite fit the bill  
> in that case.

Jon. i think you mis-understand LLSD. there is nothing in the LLSD  
specification that REQUIREs a schema be defined. In the current  
implementations of LLSD, it is not considered a transport-layer error  
to  add an additional field, or even to drop one that's defined by an  
application protocol. In this sense XML is more restrictive because it  
REQUIRES you to create a new DTD to extend an existing message flow  
(though presumably you would configure your DTDs or Schemas to be  
easily extensible.)

for instance.. if a parameter was defined as:

    &response = {
      success     : false ,
      description : string ,
      err_num     : integer
    }

    &response = {
      success     : true,
      description : string
    }
    %% foo <- undef -> & response
and you received an XML serialization that looked like:

<llsd>
   <map>
     <key>success</key>
     <boolean>true</boolean>
     <key>something_i_like_to_eat_on_sundays</key>
     <string>bananas</string>
   </map>
</llsd>

this i not an error. an implementation that attempted to get the value  
of "description" field from the map would retrieve the default for  
type string (i.e. - a zero length string.) that the  
'something_i_like_to_eat_on_sundays' information is passed may be a  
waste of bandwidth, but it might also be a new message format unknown  
by the consumer. a system that ignores unexpected input is a system  
that has a fighting chance of not having to upgraded in tandem with  
the client.

> If I want to send a piece of data from point A to point B, and point  
> A and point B know exactly what this data will be, then data type  
> information does not need to be sent as part of the serialization.  
> In fact, including data type information is redundant and consumes  
> network bandwidth unnecessarily.

however, sending type information in the serialization allows  
intermediary systems to reason about the content of the data they are  
receiving and potentially make routing and caching decisions based on  
the content.

LLSD is intended to be used in a "loosely coupled" environment. one  
"feature" of such an environment is that systems be resilient in the  
face of heterogeneity in terms of component version. for example,  
consider a logging system that received logging messages from a number  
of clients and stores them for later analysis. when the system is  
initially deployed, messages may be defined as the tuple (source,  
severity, description). it is not difficult to imagine the situation  
where one client wishes to add a value to that tuple to make it  
(source, facility, severity, description). in tightly bound systems,  
you might create a new message PDU format, but both the client and the  
server would need to know about this change at exactly the same time  
(otherwise the server would signal an error when it received an  
unknown message format. now imagine the mess if half of the systems  
were in one administrative domain and the rest in another.