Hi Jack,
Yes, indeed, I did misunderstand your original #2.
Between an empty list node appearing (as just "[ ]") versus not appearing at
all, I do not think that the JSON encoding is defined, and so tooling should
accept either encoding, IMO. [FWIW, XML has only one encoding].
Personally, I initially preferred #1 (because it is more self-describing), but
implementation-details drove me to #2.
Kent // contributor
> On Mar 29, 2022, at 2:19 PM, Jack Rickard <jack.rick...@microsoft.com> wrote:
>
> Hi Kent,
>
> Thanks very much for the response. However, I'm slightly worried you've
> misunderstood my examples, and as I've been fighting in the #1 corner I want
> to make sure I give #2 a fair chance.
>
> Given this schema:
> module test {
> prefix "test";
> namespace "urn:test";
>
> container test {
> leaf foo {type string;}
> leaf-list bar {type string;}
> leaf baz {type string;}
> }
> }
>
> Is this valid (#1):
> {
> "test:test": {
> "foo": "test1",
> "bar": [],
> "baz": "test2"
> }
> }
>
> and is this valid (#2):
> {
> "test:test": {
> "foo": "test1",
> "baz": "test2"
> }
> }
>
> To make sure I didn't miss something I verified this with yanglint 0.16.105
> (what ubuntu gave me), and that accepts #2 but not #1 (it rejects #1 with err
> : Invalid JSON data (unexpected value). (/test:test/bar)).
> To be really clear this is accepted:
> {
> "test:test": {
> "foo": "test1",
> "bar": ["test3"],
> "baz": "test2"
> }
> }
>
> Thanks,
> Jack
>
> From: Kent Watsen <kent+i...@watsen.net>
> Sent: 29 March 2022 18:14
> To: Jack Rickard <jack.rick...@microsoft.com>
> Cc: draft-ietf-netmod-yang-j...@ietf.org
> <draft-ietf-netmod-yang-j...@ietf.org>; netmod@ietf.org <netmod@ietf.org>
> Subject: Re: [netmod] RFC 7951 - JSON encoding of empty lists
>
> #1 is an empty list (or leaf-list). This is what you want.
>
> #2 is a list containing one element, which is an empty container (or, in
> Python term's, an empty 'dict').
>
> Yanglint 1.x used to accept #1, kinks are being worked out on the 2.x branch.
>
> Kent // contributor
>
>
>> On Mar 29, 2022, at 10:21 AM, Jack Rickard
>> <jack.rickard=40microsoft....@dmarc.ietf.org
>> <mailto:jack.rickard=40microsoft....@dmarc.ietf.org>> wrote:
>>
>> Hi,
>>
>> I think I’ve found an ambiguity in RFC 7951, and I’d like your input on what
>> was intended and what the best behaviour to exhibit is.
>>
>> Section 5.3 and 5.4 of RFC 7951 - JSON Encoding of Data Modeled with YANG
>> (ietf.org)
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7951%23section-5.3&data=04%7C01%7Cjack.rickard%40microsoft.com%7Ca33f2d22f70f4de7a87808da11a79ae4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637841709447361395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2jqJW1VVJyft9CVC3T5xCgXvlt4Zsd7c7mdtBrKSpdM%3D&reserved=0>
>> describe the encoding of leaf-lists and lists, however it’s unclear how an
>> empty list should be encoded. Should it be encoded as:
>> An empty array: {“list”: []}
>> A missing field: {}
>>
>> I’ve seen libraries go either way, libyang only accepts 2 but the python
>> yangson library accepts both (I’m not sure which is the default).
>>
>> Thanks,
>> Jack Rickard
>> he/him
>> Software Engineer
>> jack.rick...@microsoft.com <mailto:jack.rick...@microsoft.com>
>>
>> <image001.png>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=04%7C01%7Cjack.rickard%40microsoft.com%7Ca33f2d22f70f4de7a87808da11a79ae4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637841709447361395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=RJxmETMYeLjdtqejd%2BsfV6jkjjAuQAxZ%2FeQkf14lZT0%3D&reserved=0>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
