> 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”.
Lada
>
> 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
