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

Lada


> 
> 
> /martin
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to