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

[David W Levine <[e-mail]>]

[e-mail] 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:
> 
> [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?
> 


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