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

hmm. this case is actually covered in the draft. i'll have to recode
some things if we change it.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com


On Wed, Mar 31, 2010 at 3:14 PM, David W Levine <dwl@us.ibm.com> wrote:
>
> vwrap-bounces@ietf.org wrote on 03/31/2010 05:53:25 PM:
>
>> [image removed]
>>
>> [vwrap] Parsing of invalid LLSD elements in XML
>>
>> Joshua Bell
>>
>> to:
>>
>> vwrap
>>
>> 03/31/2010 05:53 PM
>>
>> Sent by:
>>
>> vwrap-bounces@ietf.org
>>
>> 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?
>>
>
>
> My fairly strong preference is for choice (3). Choice (2) allows an error to
> propagate
> in ways which strikes me as highly undesirable. Choice (1) stops the error
> from propagating
> but likely at the expense of generating the error detection some distance
> from a good place
> to actually handle the error. The element is invalid, the elements framing
> it (in this example,
> the map) is valid, and allows the error to be stated quite explicitly.
>
>
> - David
> ~ Zha
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>