> On 09 Sep 2016, at 16:07, Andy Bierman <[email protected]> wrote: > > > > On Fri, Sep 9, 2016 at 6:44 AM, Ladislav Lhotka <[email protected]> wrote: > "Dale R. Worley" <[email protected]> writes: > > > Andy Bierman <[email protected]> writes: > >> Using a key of type empty is utterly pointless unless the point > >> is to make the instance identifier longer. > > > > IMO using a key of type empty (or any type with only one value) is > > *pointless* but should be *valid*. Things should be valid unless > > processing them according to the ordinary rules can't work. Indeed, > > specifically banning them increases the complexity of the > > specification. > > +1 > > There is no need to ban keys with type "empty", XPath and everything > works fine if other YANG rules are followed. > > > > Why should YANG Doctors approve a YANG module that uses type empty as a key? > The guidelines say SHOULD NOT use empty as a key. Come up with a use-case. > (You can't). If you can, I will remove the guideline from the draft.
This is all fine, my point (and I think Dale's as well) is that it should be permitted in YANG the language, so it is a good thing that this 6020 CLR is no more present in 7950: 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". Earlier in this thread you said that we had it right in YANG 1.0, and I don't agree with that. Lada > > The YANG Guidelines draft restricts YANG usage for IETF standards track > modules. > Use lots of empty keys in your data model if you want. > > > > Lada > > > Andy > > > > > > The reason for this is that the code (in this case, the module > > definition) may be generated by an automatic process, and those > > processes are easier to construct if the rules contain fewer > > irregularities. E.g., multiplying a number by zero is pointless, in > > that the result is always zero, and one might ask, Why not just write 0 > > instead of the multiplication? But everyone agrees that the statement > > > > a = 0 * b; > > > > is *valid*, and can easily imagine situations where a process might > > generate it as an output. > > > >>> Unless I'm off, the line should be fixed to avoid the string > >>> conversion: > >>> > >>> /ex:system/ex:service[ex:name='foo'][ex:enabled] > >>> > >>> and a negation should be: > >>> > >>> /ex:system/ex:service[ex:name='foo'][not(ex:enabled)] > >> > >> There is only one value provided by type empty. The 2nd instance > >> identifier is invalid. > >> There is no instance possible that does not include the 'enabled' leaf. > > > > The 2nd instance identifier is (should be) *valid* even if it always > > returns the empty set. (Assuming it is used in contexts where a set can > > be returned.) > > > > Dale > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
