Re: [netmod] Yang 1.1 change: Allow type "empty" in a key.

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.
________________________________________
Od: Jernej Tuljak <jernej.tuljak@mg-soft.si>
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); netmod@ietf.org
Predmet: RE: [netmod] Yang 1.1 change:  Allow type "empty" in a key.

> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Wednesday, February 15, 2017 11:40 AM
> To: Jernej Tuljak <jernej.tuljak@mg-soft.si>
> Cc: Alex Campbell <Alex.Campbell@Aviatnet.com>; Martin Ciglan -X (mciglan
> - PANTHEON TECHNOLOGIES at Cisco) <mciglan@cisco.com>; Igor Foltin -X
> (ifoltin - PANTHEON TECHNOLOGIES at Cisco) <ifoltin@cisco.com>;
> netmod@ietf.org
> Subject: Re: [netmod] Yang 1.1 change: Allow type "empty" in a key.
>
>
> > On 15 Feb 2017, at 11:16, Jernej Tuljak <jernej.tuljak@mg-soft.si> 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:netmod-bounces@ietf.org] On Behalf Of Alex
> Campbell
> > Sent: Tuesday, February 14, 2017 9:59 PM
> > To: Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)
> <mciglan@cisco.com>
> > Cc: Igor Foltin -X (ifoltin - PANTHEON TECHNOLOGIES at Cisco)
> <ifoltin@cisco.com>; netmod@ietf.org
> > 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 <netmod-bounces@ietf.org> on behalf of Martin Ciglan -X
> (mciglan - PANTHEON TECHNOLOGIES at Cisco) <mciglan@cisco.com>
> > Sent: Wednesday, 15 February 2017 2:48 a.m.
> > To: netmod@ietf.org
> > 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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>