[vwrap] Parsing of invalid LLSD elements in XML

[Joshua Bell <[e-mail]>]

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?