Ladislav Lhotka <[email protected]> wrote: > > > On 25 Aug 2015, at 14:01, Martin Bjorklund <[email protected]> wrote: > > > > Hi, > > > > I think this could work (thanks Robert; maybe this is what you > > meant!): > > > > container zones { > > list zone { > > ... > > list rrset { > > ... > > leaf type { > > type identityref { ... } > > } > > list rdata { > > key id; > > ... > > choice type-specific-params { > > mandatory true; > > // to be augmented with type-specific nodes > > } > > } > > } > > } > > } > > > > And then in another module: > > > > augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" > > + "/type-specific-parameters" { > > when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > > + "'TLSA')"; > > > > leaf certificate-usage { > > mandatory true; > > ... > > } > > } > > > > The empty mandatory choice formally tells the client that additional > > cases are expected. > > > > (If the empty choice looks fishy, it is probably often possible to > > define at least one case inline...) > > > > This pattern is nice to the client, since there is no way an > > additional augmenting module can break a working client. > > Yes, I just tried very similar test modules with pyang, and DSDL seems > to validate instance data as expected: at least one case has to be > present, so no valid instance exists for the “abstract” module alone. > > I think it is a better approach to subclassing than augment+when.
It is augemnt-choice+when. I agree it solves the "subclassing" use case, but it has its limitations. For example, you cannot have two separate modules augment with the same type. But then, in such a case you can still to the old augment-p-container+when. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
