Re: [mmox] The Structure and Interpretation of LLSD Messages [Was: Re: unefficient binary serialization ?]

[Lisa Dusseault <[e-mail]>]

I really think this is a key difference between good design for an
extensible single-party (or at least single-change-owner) protocol,
and good design for an interoperable standard.  The reason is that we
want to shut down extensibility where it would hurt interoperability
and backward-compatibility.  The result of designing like this means
that there are some ways you can't extend the standard; extensions are
more limited in the creative ways they can be applied.

IOW, the tradeoffs for extensibility are different in standards than
for a protocol controlled by one host, e.g. Google PB.

More inline:

On Tue, Feb 24, 2009 at 9:41 PM, Meadhbh Hamrick (Infinity)
<[e-mail]> wrote:
>
> ...
>
> now.. imagine we have a PDU with three members while the second version adds a member. for simplicity's sake, let's say they're all integers.
>
> if used the DTD to define the validation for the message, the first version of the message might look like:
>
> <?xml version="1.0"?>
> <!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly Defined Derivatives ML PDU 1.0//EN" "http://example.com/pdu/1.0/pdutastic.dtd">
> <pdutastic>
>  <foo type="integer">13</foo>
>  <bar type="integer">42</bar>
>  <baz type="integer">93</baz>
> </pdutastic>
>
> while the new version would look like this:
>
> <?xml version="1.0"?>
> <!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly Defined Derivatives ML PDU 1.1//EN" "http://example.com/pdu/1.1/pdutastic.dtd">
> <pdutastic>
>  <foo type="integer">13</foo>
>  <bar type="integer">42</bar>
>  <baz type="integer">93</baz>
>  <qux type="integer">161</qux>
> </pdutastic>
>
> so when i (expecting the new version) consume the old version, i do not see qux. but my parser doesn't complain because instead of the DTD of the new PDU, i see a reference to the old PDU and say to myself... "it's okay... it's just an older version," and i do whatever i have to do to continue processing in the absence of the qux member i was expecting. even if i'm doing validation, it's okay, i'm pulling the DTD from the old definition, so we're cool.

Excellent example, totally agree.

>
> now... when cathy consumes the new PDU, something similar happens. she see's a DTD she's not familiar with, but it's all good.. she grabs teh DTD from URL specified in teh DOCTYPE and moves on with her life, hoping that new version PDU didn't change the semantics of the three values (foo, bar and baz) she's familiar with.
>
> and then one day she receives this from david:
>
> <?xml version="1.0"?>
> <!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly Defined Derivatives ML PDU 1.2//EN" "http://example.com/pdu/1.2/pdutastic.dtd">
> <pdutastic>
>  <foo type="integer">13</foo>
>  <bar type="date">2008-12-15T13:17:23.235Z</bar>
>  <baz type="integer">93</baz>
>  <qux type="integer">161</qux>
> </pdutastic>
>
> but this is now a serious problem for cathy. the "shape" of the structured data now does not match. what does she do? how does she convert that date into an integer?

In a *standard*?  Cathy does not.  She flags an error.  The standard
that would have produced the interoperability so far in your example
would have said "bar is an integer".

In fact, if there's agreed interoperability between Cathy, Meadhbh and
David on the foo, bar and baz semantics, then none of them need to be
annotated with their datatypes.



<?xml version="1.0"?>
<!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly Defined Derivatives ML PDU
1.2//EN" "http://example.com/pdu/1.2/pdutastic.dtd">
<pdutastic>
   <foo>13</foo>
   <bar>2008-12-15T13:17:23.235Z</bar>
   <baz>93</baz>
   <qux type="integer">161</qux>
</pdutastic>

Result?  Cathy returns an error because her XML handling looks like this:

try:
    barval = int(xmldoc.getElementsByTagName('bar').data)
except ValueError:
    return new ErrorResponse(400, "Bad Request")


Whether there is a role for marking some things as "integer" types
right in the protocol, I don't know.  But if there's agreed semantics
for an operation like "I would like to send you a user to rez with the
following avatar information in the following location which may be
valid in your world", then the location semantics are probably solid
enough to do mostly by marking an integer as an integer in the
specification, once and for all, rather than in every request.

Lisa