> -----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
>
>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
