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

[Ladislav Lhotka <[e-mail]>]

Christian Hopps <[e-mail]> writes:

>> On Dec 18, 2021, at 7:59 AM, Carsten Bormann <[e-mail]> wrote:
>> 
>> On 2021-12-18, at 09:20, Eliot Lear <[e-mail]> wrote:
>>> 
>>> Still it seems like the right thing to do, in order to fall into line with the target language spec.
>> 
>> But that’s not what YANG was designed for.
>> YANG is a data modeling language, which incidentally has a couple of representation formats (YANG-XML, YANG-JSON, YANG-CBOR).
>> There is no intention for the YANG generic data model (the set of all data models YANG can express) to cover the generic data model of the representation format.
>
> To be clear, the question I raised is about an encoding of YANG modeled data. In particular the JSON encoding of the YANG empty leaf element.
>
>   https://datatracker.ietf.org/doc/html/rfc7951#section-6.9
>
> the justification for having the very odd encoding was that there was some belief that some programming languages might have trouble with the obvious JSON "null" encoding (which stands for "no value" in JSON -- exactly what we want here). An old email gave a python example to try and illustrate this, except the python example was an incorrect use of python for this case (presence check) and not a problem with the natural JSON encoding for no value items. In fact correctly written python code has no problem at all with the more natural "null" encoding, and results in the correct internal representation in python to boot.
>
> This isn't about the YANG specification in general, or making YANG
> conform to any particular language. It's just about the a choice in
> the specification for the encoding of YANG in a particular format
> (JSON).

The original proposal (even before my individual draft appeared in the NETMOD WG) was actually just "null". We'd been discussing it back in March 2012 in a smaller group (Andy, Jürgen, Martin, Phil Shafer and myself), and Phil objected to this encoding of empty values. His arguments were, for example:

    'foo: null'?  Doesn't that make testing for empty values a major
    pain?  'if (foo)' would not work.

    JSON evolved from Javascript, so it must keep the javascript
    meanings for these keywords.

It is indeed true that tests in JavaScript cannot really distinguish between a non-existent member and member with the value of 'null'. I remember I wasn't happy about this change but I thought it wasn't a big deal.

Lada

>
> Thanks,
> Chris.
>
>
>
>> 
>> While RFC 8791 (and before it RFC 8040) extended YANG to be able to describe data in flight, there is no intention that YANG can be used to describe the entire expressibility of the representation format.  We have Relax-NG, CDDL, and a few other modeling approaches if we need that.
>
>> Grüße, Carsten
>> 
>

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67