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

[Meadhbh Hamrick <[e-mail]>]

heck. discord already? that's got to be a record, david. normally we
have to wait at least a couple hours to work up a really good
technical disagreement. ;-)

before i go off about how good it is to reduce the impact of version
skew, let me say i totally get your answer. it reminds me a bit of the
gulf between lovers of dynamic and statically typed languages. one of
the criticisms i hear over and over again about javascript and python
is that it's very easy for programmers to mistakenly mistype a member
name and for it to be vaguely difficult to find the error. static
typing fans frequently say dynamic languages allow errors in code to
propagate and make it hard to pin down the cause of the error. dynamic
language fans reply with long and drawn out descriptions for why the
fragile base class problem is evil. and so it goes back and forth
until functional language fans go off and make type inferring
languages with the intent of making the C++ and python fans heads'
explode.

this is the point in a typical rant where the author predicts dire
consequences if the group chooses incorrectly. so include your
favorite prediction of dire consequences here.

seriously though. i think this is the type of thing we need to think
about a little bit more. david, you want to find some time to work
through some examples next week?

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Wed, Mar 31, 2010 at 3:14 PM, David W Levine <[e-mail]> wrote:
>
> [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
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>