On Mon, Sep 7, 2015 at 9:50 AM, Ladislav Lhotka <[email protected]> wrote:
> > > On 07 Sep 2015, at 18:37, Robert Wilton <[email protected]> wrote: > > > > Hi Lada, > > > > Thanks for the explanation. > > > > Initially I was concerned that there would be a higher server > implementation cost of using a must statement over a when statement, but > given that the container/leaves are under a choice statement then it seems > that the must statement can presumably be implemented as efficiently as a > when statement in this scenario. > > Well, if “when” was limited to the most common case like > > container foo { > when “../type = ‘foo’”; > } > > then it would indeed be possible to have a more efficient (generic) > implementation of “when”. But since it may contain essentially arbitrary > XPath expressions, implementation cost of “when” should be at least as high > as that of “must”. > > when-stmt is much harder to implement correctly than must-stmt. The use of 'must' vs. 'when' depends on which data structure is primary and which is secondary. must-stmt is for use in the primary data node. It says "if I exist then you must pass this validation test". when-stmt is for secondary data structures. It says "I exist if your settings pass this test". > Lada > Andy > > > > > Thanks, > > Rob > > > > > > On 07/09/2015 11:52, Ladislav Lhotka wrote: > >> 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 > >> > >> > >> > >> > >> . > >> > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
