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]>]

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