> On 15 Feb 2017, at 15:56, Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES > at Cisco) <[email protected]> wrote: > > Thanks for information, but still, from implementation point of view, > we've got empty keys in Map structures, searching for values... > that was my point.
So what's your problem with them? Lada > ________________________________________ > Od: Jernej Tuljak <[email protected]> > Odoslané: 15. februára 2017 13:27 > Komu: 'Ladislav Lhotka' > Kópia: 'Alex Campbell'; Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at > Cisco); Igor Foltin -X (ifoltin - PANTHEON TECHNOLOGIES at Cisco); > [email protected] > Predmet: RE: [netmod] Yang 1.1 change: Allow type "empty" in a key. > >> -----Original Message----- >> From: Ladislav Lhotka [mailto:[email protected]] >> Sent: Wednesday, February 15, 2017 11:40 AM >> To: Jernej Tuljak <[email protected]> >> Cc: Alex Campbell <[email protected]>; Martin Ciglan -X (mciglan >> - PANTHEON TECHNOLOGIES at Cisco) <[email protected]>; Igor Foltin -X >> (ifoltin - PANTHEON TECHNOLOGIES at Cisco) <[email protected]>; >> [email protected] >> Subject: Re: [netmod] Yang 1.1 change: Allow type "empty" in a key. >> >> >>> On 15 Feb 2017, at 11:16, Jernej Tuljak <[email protected]> wrote: >>> >>> Plus, "empty keys" were aready allowed in YANG 1. >> >> Well, keys with "empty" type were not allowed. What you are saying is that >> the same (dubious) effect can be achieved in other ways that were >> permitted in YANG 1. > > Indeed. I meant »empty keys«. Quoting is hard. :) > > Jernej > >> Note also that while if in XML encoding an empty leaf >> and a leaf containing string of length 0 look the same, in JSON encoding they >> are different: >> >> "first": [null] >> >> versus >> >> "first": "" >> >>> >>> module empty-key { >>> namespace "org:example:empty-key"; >>> prefix "ek"; >>> >>> container stuff { >>> list item { >>> key "first second"; >>> leaf first { >>> type string { >>> length 0; >>> } >>> } >>> leaf second { >>> type string { >>> pattern '.{0}'; >>> } >>> } >>> } >>> } >>> } >>> >>> Therefore this change removed a redundant (perhaps even broken) rule. >> >> Agreed. >> >> Lada >> >>> >>> https://www.ietf.org/mail-archive/web/netmod/current/msg16763.html >>> Jernej >>> >>> From: netmod [mailto:[email protected]] On Behalf Of Alex >> Campbell >>> Sent: Tuesday, February 14, 2017 9:59 PM >>> To: Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco) >> <[email protected]> >>> Cc: Igor Foltin -X (ifoltin - PANTHEON TECHNOLOGIES at Cisco) >> <[email protected]>; [email protected] >>> Subject: Re: [netmod] Yang 1.1 change: Allow type "empty" in a key. >>> >>> Hi, >>> >>> It means exactly what the summary says. In YANG 1.0 (RFC 6020) we have: >>> A leaf that is part of the key can be of any built-in or derived >>> type, except it MUST NOT be the built-in type "empty". >>> and in YANG 1.1 (RFC 7950) we have: >>> A leaf that is part of the key can be of any built-in or >>> derived type. >>> >>> In YANG 1.1, leaves of type "empty" are not disallowed from being keys. >>> >>> Note that since leaves of type "empty" only convey information through >> their presence or absence, and since >>> key leaves must always be present, key leaves of type "empty" convey no >> useful information. >>> >>> Alex >>> >>> >>> From: netmod <[email protected]> on behalf of Martin Ciglan -X >> (mciglan - PANTHEON TECHNOLOGIES at Cisco) <[email protected]> >>> Sent: Wednesday, 15 February 2017 2:48 a.m. >>> To: [email protected] >>> Cc: Igor Foltin -X (ifoltin - PANTHEON TECHNOLOGIES at Cisco) >>> Subject: [netmod] Yang 1.1 change: Allow type "empty" in a key. >>> >>> Hi all >>> >>> Yang 1.1 change: Allow type "empty" in a key. >>> >>> What is the meaning of this change? We're interested from >> implementation point of view. >>> >>> Thanks >>> >>> Martin >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> >> >> > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
