Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Robert Wilton <[e-mail]>]

On 23/11/2018 13:29, Ladislav Lhotka wrote:
> On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
>> On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
>>>> Here is an attempt to rewrite things in a way according to how I
>>>> understand things works. It should be possible to describe what we
>>>> mean. If we can't do that, we have a bigger problem. (I have changed
>>>> only the last two sentences.)
>>>>
>>>> OLD
>>>>
>>>>     The leafref built-in type is restricted to the value space of some
>>>>     leaf or leaf-list node in the schema tree and optionally further
>>>>     restricted by corresponding instance nodes in the data tree.  The
>>>>     "path" substatement (Section 9.9.2) is used to identify the referred
>>>>     leaf or leaf-list node in the schema tree.  The value space of the
>>>>     referring node is the value space of the referred node.
>>>>
>>>> NEW
>>>>
>>>>     The leafref built-in type is restricted to the value space of some
>>>>     leaf or leaf-list node in the schema tree and optionally further
>>>>     restricted by corresponding instance nodes in the data tree.  The
>>>>     "path" substatement (Section 9.9.2) is used to identify a leaf or
>>>>     leaf-list node in the data tree. The value space of the leafref
>>>>     node is determined by the value space of the schema tree node
>>> The term "value space of a schema tree node" is not defined.
>> OK. So we say 'the value space of the type of the schema tree node'.
> Yes, this is better. But what if the schema tree node is made invalid due to a
> failed "when" expression? Does it still apply?

I might be being picky, but it isn't absolutely clear from the text 
which node "schema tree node" refers to.

Hence I wonder whether it might be better to say "...identify the 
referenced leaf or leaflist ..." and "value space of the referenced 
schema tree node".

Thanks,
Rob


>
>>   
>>>>     definining the referenced data tree node.
>>> With require-instance=false there needn't be any referenced data tree node.
>> So we add "(irrespective whether the node exists or not).
> If the data tree node doesn't exist, we cannot refer to the schema tree node
> that defines it.
>
>>>> This likely is not perfect yet but perhaps we manage to make it
>>>> perfect. ;-) What is not yet clearly described I think is what
>>>> 'further restricted by corresponding instance nodes in the data tree'
>>>> means (and that I think depends on require-instance). Perhaps add
>>> Right. In this case it is not "further restricted" but rather there is a
>>> discrete set of possible values.
>> A discrete set of possible values is a restriction so I do not
>> understand your comment. So here is the next iteration:
> If required-instance is true, there is no need to care about all this tricky
> stuff with schema tree nodes and their types. In other words:
>
> 1. if required-instance = true, the permitted values are obtained from the data
> tree.
>
> 2. if required-instance = false, the corresponding schema node has to be
> determined, and its type defines the permitted values of the leafref node.
>
> It is an exclusive-or, #1 is not an "optional further restriction".
>
> Lada
>
>> NEW:
>>
>>      The leafref built-in type is restricted to the value space of some
>>      leaf or leaf-list node in the schema tree and optionally further
>>      restricted by corresponding instance nodes in the data tree (see
>>      Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
>>      to identify a leaf or leaf-list node in the data tree. The value
>>      space of the leafref node is determined by the value space of the
>>      type of the schema tree node definining the referenced data tree
>>      node (irrespective whether the referenced data tree node exists or
>>      not).
>>
>> /js
>>