Re: [netmod] augment and if-feature

[Robert Wilton <[e-mail]>]

On 17/03/2017 14:03, Dale R. Worley wrote:
> Robert Wilton <[e-mail]> writes:
>> To quote Joey's example,  I think that both of the following modules are
>> valid (presuming that they are both implemented by a device) regardless
>> of which features are enabled.  Do you agree?
>>
>> module base-module {
>>     prefix bmod;
>>
>>     feature things;
>>     feature widgets;
>>
>>     container things {
>>       if-feature things;
>>       ...
>>       container widgets {
>>         if-feature widgets;
>>         ...
>>       }
>>     }
>> }
>>
>> module augment-module {
>>     prefix amod;
>>
>>     augment "/bmod:things" {
>>       container other-things {
>>       }
>>     }
>>
>>     augment "/bmod:things/bmod:widgets" {
>>       container other-widgets {
>>       }
>>     }
>> }
> Does it remain valid if base-module is changed to:
>
>      module base-module {
>         prefix bmod;
>
>         feature things;
>         feature widgets;
>
>         container things {
>           if-feature things;
>           ...
>           }
>         }
>      }
No, I don't think that it is valid because this augment fails because 
the base node "/bmod:things/bmod:widgets" doesn't exist.

>
> As I analyze it, the augment statement is unconditional, but the
> presence of its target node can be (1) unconditional, (2) conditional,
> or (3) *never* present.
>
> My preferred approach is that an augment is only valid if it is
> "present" only if the target node is present (a condition I think can be
> verified statically).  But if we allow the augment to silently have no
> effect if the target node is not present in the current implementation,
> do we still require that there is some possible implementation in which
> the target node exists?
I guess that I think that a node with an if-feature stmt is logically 
present in the schema (and hence can always be augmented), but just that 
it (and its descendant nodes) can be supported/unsupported depending on 
what features a device advertises that it is supporting.

But I don't think that means that an augmentation is ever is ignored, 
but it might add nodes to the schema tree that aren't supported because 
a given feature isn't supported.

Phil's example of a feature that relates to whether an SD card is 
present is interesting because it gives an example of when it might be 
useful to dynamically modify the set of supported features whilst a 
device is running.  Likewise, I could see how the features could change 
due to adding/removing software components, or different revisions of 
hardware.

Thanks,
Rob

>
> Dale
> .
>