> On 30 May 2016, at 12:10, Martin Bjorklund <[email protected]> wrote: > > Ladislav Lhotka <[email protected]> wrote: >> >>> On 30 May 2016, at 10:58, Ladislav Lhotka <[email protected]> wrote: >>> >>>> >>>> On 30 May 2016, at 10:49, Martin Bjorklund <[email protected]> wrote: >>>> >>>> Ladislav Lhotka <[email protected]> wrote: >>>>> Martin Bjorklund <[email protected]> writes: >>>>> >>>>>> Juergen Schoenwaelder <[email protected]> wrote: >>>>>>> On Tue, May 24, 2016 at 10:33:29AM +0200, Martin Bjorklund wrote: >>>>>>>> Juergen Schoenwaelder <[email protected]> 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. > > Ok, but s/instance/node/.
Yes, right. Lada > > > /martin > > > >> >> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> 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
