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

How are (2) and (3) different in practice? My understanding is that
the undefined value has conversions to string, uuid, date, etc and
will convert as the default value for each type.

I think (2) is the current behavior of OpenMetaverse.StructuredData
but it can be changed in the future.

John

On Wed, Mar 31, 2010 at 2:53 PM, Joshua Bell <josh@lindenlab.com> 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
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>