Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)]

[Eliot Lear <[e-mail]>]

Just following this up, I see in my own work it occurs a little bit, so 
it is out there.  It doesn't create ambiguities, tho, because it is used 
in null-valued leafs.  It just creates syntax breakage.  Some parsers 
will have a problem with recognizing a naked null as valid.  On the 
other hand, in the case of MUD, we separately added versioning into the 
model, so we could bump this if the serialization updates.

On 18.12.21 09:20, Eliot Lear wrote:
>
> Possibly.  The issue with fixing it is that it would create an 
> ambiguity between null and [  null ].  I am not sure how often [ null 
> ] would not have that semantic equivalence in earlier work.  This is 
> further complicated by a lack of self-descriptive versioning in YANG 
> serializations.
>
> Still it seems like the right thing to do, in order to fall into line 
> with the target language spec.
>
> Eliot
>
> On 18.12.21 07:47, Christian Hopps wrote:
>> Hi,
>>
>> I was just going over json encoding of YANG, and got to the empty 
>> leaf encoding and it's odd use of "[null]" rather than just "null". I 
>> read the explanation, but had a hard time believing what it said. So, 
>> running code time. The first thing I tried was Python to see if 
>> something weird happened:
>>
>>     In [1]: import json
>>     In [2]: json.loads('{"foo": null}')
>>     Out[2]: {'foo': None}
>>
>> Nope, seems fine. Then checked the "definitive source" for json, 
>> javascript:
>>
>>     js> JSON.parse("{\"foo\": 1, \"bar\": null}")
>>     ({foo:1, bar:null})
>>
>>
>> Seems fine here too..
>>
>> So I went searching the mailing list and found this:
>>
>>>     On Jun 29, 2015, at 5:49 AM, Ladislav Lhotka <[e-mail]> wrote:
>>>     Juergen Schoenwaelder <[e-mail]> writes:
>>     ...
>>>>     - I am not sure I understand the argument why [null] is better than
>>>>      null for the empty type. Perhaps it is but the text does not
>>>>     really
>>>>      tell me.
>>>
>>>     "foo": null
>>>
>>>     may sometimes appear as if the "foo" instance is not present at
>>>     all - in
>>>     some languages this is probably more serious than in others.
>>>     This is how
>>>     it works in Python:
>>>
>>>>>>     import json
>>>>>>     obj = json.loads('{"foo": null, "bar": [null]}')
>>>>>>     "YES" if obj["foo"] else "NO"
>>>     'NO'
>>>>>>     "YES" if obj["bar"] else "NO"
>>>     'YES'
>>>
>>>     So the special value "[null]" seems safer and it cannot appear
>>>     in any
>>>     other context.
>>
>> The justifying example here is, unfortunately, wrong. One does not 
>> (normally) check for the presence of a dictionary item in python by 
>> trying to access the value of that item (which is what the code above 
>> is doing). The standard python code to check for the presence of an 
>> item is as follows, and it works fine with a "null" json value:
>>
>>     In [1]: import json
>>     In [2]: o = json.loads('{"foo": null}')
>>     In [3]: o
>>     Out[3]: {'foo': None}
>>     In [4]: "YES" if "foo" in o else "NO"
>>     Out[4]: 'YES'
>>
>> Indeed in python if you try and check for a missing item the way the 
>> email above describes, and the item is missing, an exception is raised:
>>
>>     In [5]: o["bar"]
>>     ---------------------------------------------------------------------------
>>     KeyError                                Traceback (most recent
>>     call last)
>>
>>
>> One *could* catch the "KeyError" to check for missing items which 
>> will also work using "null" son values for empty leafs, but the more 
>> common form is "if key in dict" in my experience.
>>
>> Furthermore, using "access the value" for presence check will also 
>> "fail" for zero values and for empty strings, but we don't have odd 
>> encodings for integers or strings...
>>
>>     In [1]: import json
>>     In [2]: o = json.loads('{"foo": 0, "bar": ""}')
>>     In [3]: o
>>     Out[3]: {'foo': 0, 'bar': ''}
>>     In [4]: "YES" if o["foo"] else "NO"
>>     Out[4]: 'NO'
>>     In [5]: "YES" if o["bar"] else "NO"
>>     Out[5]: 'NO'
>>
>>
>> Point being, evaluating an items value is not the right way to check 
>> for "presence", it's the way to check the "value" of the item. An 
>> empty leaf has no value so it's basically never correct to try to 
>> access that value in code.
>>
>> Javascript is basically the same as python here:
>>
>>     js> o = JSON.parse('{"foo": null}')
>>     ({foo:null})
>>     js> if ("foo" in o) { "YES" } else { "NO" }
>>     "YES"
>>
>>
>> So, do we think it would it ever be possible to change (fix) this 
>> encoding oddity?
>>
>> Thanks,
>> Chris.
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod