> On 30 May 2016, at 10:58, Ladislav Lhotka <lho...@nic.cz> wrote:
>
>>
>> On 30 May 2016, at 10:49, Martin Bjorklund <m...@tail-f.com> wrote:
>>
>> Ladislav Lhotka <lho...@nic.cz> wrote:
>>> Martin Bjorklund <m...@tail-f.com> writes:
>>>
>>>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote:
>>>>> On Tue, May 24, 2016 at 10:33:29AM +0200, Martin Bjorklund wrote:
>>>>>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote:
>>>>>>> On Mon, May 23, 2016 at 05:29:42PM +0200, Ladislav Lhotka wrote:
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>> This mixes up paths in the data tree with those in the schema tree.
>>>>>>>> The XPath expression in the "path" statement is evaluated in the
>>>>>>>> context of a data tree, but if the result is an empty node set, then
>>>>>>>> "this leaf node" makes no sense.
>>>>>>>>
>>>>>>>> A specific example:
>>>>>>>>
>>>>>>>> leaf fooref {
>>>>>>>> type leafref {
>>>>>>>> path "../foo";
>>>>>>>> require-instance false;
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> leaf foo {
>>>>>>>> type uint8;
>>>>>>>> when "../bar < 42";
>>>>>>>> }
>>>>>>>>
>>>>>>>> leaf bar {
>>>>>>>> type uint8;
>>>>>>>> default 100;
>>>>>>>> }
>>>>>>>>
>>>>>>>> If there is neither "foo" nor "bar" in the data tree, what is the
>>>>>>>> value space of "fooref"?
>>>>>>>>
>>>>>>>
>>>>>>> Hm. Is it not both? The path refers to a schema node in order to
>>>>>>> determine the base type (which is the base value set if
>>>>>>> require-instance is false). If require-instance is true, then there is
>>>>>>> an additional constraint that refers to a set of data nodes that
>>>>>>> essentially determine a (possibly empty) subset of the value space.
>>>>>>>
>>>>>>> If you agree with this, then we essentially have to phrase this
>>>>>>> clearly.
>>>>>>
>>>>>> Exactly. My proposal was:
>>>>>>
>>>>>> OLD:
>>>>>>
>>>>>> The leafref type is used to declare a constraint on the value space
>>>>>> of a leaf, based on a reference to a set of leaf instances in the
>>>>>> data tree. The "path" substatement (Section 9.9.2) selects a set of
>>>>>> leaf instances, and the leafref value space is the set of values of
>>>>>> these leaf instances.
>>>>>>
>>>>>> If the leaf with the leafref type represents configuration data, and
>>>>>> the "require-instance" property (Section 9.9.3) is "true", the leaf
>>>>>> it refers to MUST also represent configuration. Such a leaf puts a
>>>>>> constraint on valid data. All such nodes MUST reference existing
>>>>>> leaf instances or leafs with default values in use (see Section 7.6.1
>>>>>> and Section 7.7.2) for the data to be valid. This constraint is
>>>>>> enforced according to the rules in Section 8.
>>>>>>
>>>>>> NEW:
>>>>>>
>>>>>> The leafref type is used to declare a constraint on the value space
>>>>>> of a leaf, based on a reference to a set of leaf instances in the
>>>>>> data tree. The "path" substatement (Section 9.9.2) is used to refer
>>>>>> to another leaf node. The leafref value space is the value space of
>>>>>> this leaf node.
>>>>>>
>>>>>> If the "require-instance" property is "true", there MUST exist an
>>>>>> instance, or a leaf with a default value in use (see Section 7.6.1
>>>>>> and Section 7.7.2), of the leaf being referred to with the same value
>>>>>> as the leafref value in a valid data tree.
>>>>>>
>>>>>> If the leaf with the leafref type represents configuration data, and
>>>>>> the "require-instance" property (Section 9.9.3) is "true", the leaf
>>>>>> it refers to MUST also represent configuration.
>>>>>>
>>>>>>
>>>>>> Please comment and/or suggest improvements to this proposal.
>>>>>>
>>>>>
>>>>> I will give it a try. I think it is helpful to define referring node
>>>>> and referred node
>>>>
>>>> Ok.
>>>>
>>>>> and I think it is useful to first state the purpose
>>>>> of the leafref type.
>>>>>
>>>>> The leafref type is restricted to the value set of some leaf node in
>>>>> the schema tree and optionally further restricted by corresponding
>>>>> instance nodes in the data tree. More precisely, the leafref type
>>>>> declares a constraint on the value space of a leaf node (the
>>>>> referring leaf node), based on a reference to a another leaf node in
>>>>> the schema tree (the referred leaf node). The "path" substatement
>>>>> (Section 9.9.2) is used to identify the referred leaf node in the
>>>>> schema tree. The value set of the referring leaf node is the value
>>>>> set of the referred leaf node if the "require-instance" property is
>>>>> "false".
>>>>
>>>> Maybe remove the second sentence. Also s/value set/value space/.
>>>> Also the last sentence isn't correct; the value space is always the
>>>> value space of the referred node.
>>>>
>>>>> If the "require-instance" property is "true", there MUST exist an node
>>>>> in the data tree, or a node with a default value in use (see Section
>>>>> 7.6.1 and Section 7.7.2), of the referred schema tree leaf node with
>>>>> the same value as the leafref value in a valid data tree.
>>>>>
>>>>> If the referring leaf node represents configuration data, and the
>>>>> "require-instance" property (Section 9.9.3) is "true", the referred
>>>>> leaf node MUST also represent configuration.
>>>>
>>>> Also, the text needs to mention leaf-lists. This gives:
>>>>
>>>>
>>>> The leafref 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.
>>>
>>> The term "value space" is not defined in 6020bis, but IMO this is not
>>> correct.
>>> For example:
>>>
>>> leaf foo {
>>> type uint8;
>>> must ". mod 2 = 0";
>>> }
>>>
>>> Arguably, the value space of this leaf consists only of even
>>> numbers.
>>
>> No. The value space is all of uint8. In the candidate you can have
>> foo = 43.
>>
>> The "must" expression adds a constraint.
>
> Then a definition of "value space" needs to be added to the Terminology
> section. So far, this term has been used in 6020bis only in relation to a
> data type, not a leaf/leaf-list instance.
Here is a suggestion:
o value space: For a data type, it is the set of values permitted by the data
type. For a leaf or leaf-list instance, it is the value space of its data type.
Lada
>
> Lada
>
>>
>>> If
>>> "bar" is a leafref that refers to "foo", what is its value space? My
>>> understanding is that it is the whole uint8 range, i.e. the value space
>>> of the *type* of "foo".
>>
>> Yes.
>>
>>
>> /martin
>>
>>
>>
>>>
>>> Lada
>>>
>>>>
>>>> If the "require-instance" property is "true", there MUST exist an
>>>> node in the data tree, or a node with a default value in use (see
>>>> Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf
>>>> or leaf-list node with the same value as the leafref value in a
>>>> valid data tree.
>>>>
>>>> If the referring node represents configuration data, and the
>>>> "require-instance" property (Section 9.9.3) is "true", the referred
>>>> node MUST also represent configuration.
>>>>
>>>>
>>>>
>>>> /martin
>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
