Hi Rob, I generally prefer must to when, except in augments, because it is IMO a much cleaner concept that also has analogies in standard XML schema languages. When manipulates the schema based on arbitrary values in an instance document (that is supposed to be validated with the schema), and because of that it requires extra rules and sometimes even temporary manipulation with the instance document to work correctly, see
https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-06#section-7.21.5 In contrast, must expressions are evaluated in the context of an instance document and there are no concerns about circular references, order of evaluation etc. Lada > On 07 Sep 2015, at 12:05, Robert Wilton <[email protected]> wrote: > > Hi Lada, > > I've just take a quick look at your DNS model referenced below. For your > containers under the choice rdata-content you have used must statements > to enforce the constraint. > > E.g. > > ... > choice rdata-content { > mandatory "true"; > ... > container A { > must "../../type = 'ianadns:A'"; > > > I was wondering what the reason was that you choose to use must statements > rather than equivalent when statements? > > The reason that I'm asking is that I had used when statements for a similar > construct that I had used for VLANs encapsulation, and I guess I would > normally choose a when statement out of preference over a must statement, > hence the desire to understand the rationale for the alternative. > > Thanks, > Rob > > > On 26/08/2015 09:28, Ladislav Lhotka wrote: >> Hi, >> >> I changed the DNS zone data model to use this pattern - it looks >> good and works great: >> >> - module: >> >> https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/dns-zones.yang >> >> >> - tree: >> >> https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree >> >> >> Lada >> >> Martin Bjorklund >> <[email protected]> >> writes: >> >> >>> 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. >>> >>> >>> /martin >>> >>> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
