Re: [vwrap] Parsing of invalid LLSD elements in XML

[Meadhbh Hamrick <[e-mail]>]

i have a vague memory of us agreeing in the OGP era that if a value
was invalid, you got the default. i believe the justification was the
same as why you get the default if you ask for a map entry that
doesn't exist, to cope with version skew.

it may sound weird that we would want something like that, but consider this...

in rev one of a service, you may have a map with a map entry whose
name is 'foo' and who's string value is "bar". like this:

<llsd>
  <map>
    <key>foo</key>
    <string>bar</string>
  </map>
</llsd>

the "correct" way to access this in JavaScript would be something like:

var interestingMap = LLSD.deserialize( msg )[0];
alert( interestingMap["foo"].asString() );

(other implementations like C++ and python have similar facilities to
render a value in a particular type.) now let's imagine that the next
rev of the interface changes foo to be a UUID:

<llsd>
  <map>
    <key>foo</key>
    <uuid>b42bd48f-7452-40ff-8d70-9d1b31a96cad</uuid>
  </map>
</llsd>

what should the code above do with the new LLSD above? the consensus
in the OGP era was that it SHOULD create an alert box with the string
("b42bd48f-7452-40ff-8d70-9d1b31a96cad") because the default
conversion from a UUID to a string is simply to return the textual
representation of the hex digits representing the 128 bits of the
UUID.

however, the new code:

var interestingMap = LLSD.deserialize( msg )[0];
alert( interestingMap["foo"].asUUID() );

should create an alert box with the default UUID (00000000- ... -0000)
when fed the first LLSD message above because this is the conversion
described in the document when converting non 8-4-4-4-12 strings to
uuids.

again, the justification for this was to reduce the impact of version
skew between loosely coupled services. the thinking is that since a
service that is looking at strings or UUIDs is going to have to figure
out what to do with invalid, parameters (like empty strings or default
UUIDs,) so you might as well let the application layer do it's job.

so, my vote is option 2.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Wed, Mar 31, 2010 at 2:53 PM, Joshua Bell <[e-mail]> wrote:
> Mark Lentczner and I were discussing this issue earlier today offline, and I
> wanted to recap it to the list.
> draft-hamrick-vwrap-type-system-00 does not define what should happen when
> trying to parse this LLSD XML fragment (pretend it has the right prologue
> and hence is well-formed XML):
> <llsd>
>     <map>
>         <key>test</key>
>         <uuid>this is not a uuid</uuid>
>     </map>
> </llsd>
> There are at least three reasonable outcomes:
> (1) Reject the payload entirely - the entire message should be rejected
> (2) Produces a map; value associated with key "test" is a UUID of
> 00000000-0000-0000-0000-000000000000 - which would be the result of
> converting the string "this is not a uuid" to a UUID
> (3) Produces a map; value associated with key "test" is the Undefined value
> (The map is, strictly speaking unnecessary, to the example, but it clarifies
> the context in which #3 occurs)
> This is not confined to UUIDs; similar issues occur with Date and Binary
> types in the XML serialization. The JSON serialization appears  "immune" to
> this spec ambiguity because primitive types always end up as
> Boolean/String/Real/Undefined (in LLSD parlance); conversion to
> Integer/UUID/Date/URI/Binary can only occur at the application level. The
> Binary serialization appears "immune" to the spec ambiguity as well
> (possibly edge cases if a NaN or Infinity was used for a Date?)
> Thoughts?
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>