> On 24 May 2016, at 10:33, Martin Bjorklund <[email protected]> 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
The path argument is XPath (in particular, it can contain key value predicates that can be interpreted only in an instance data tree), so it doesn't refer to a schema node. >> 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. The "path" expression is evaluated in some context that's defined in the text. The result is a node set in the *instance* data tree, and in my example this node set is empty. Yes, I understand that *usually* there is some leaf node in the schema that defines the type of the leafs selected by the XPath expression (if they existed), but I think it is problematic to simply say that an XPath expression refers to a schema node. Consider the example in Appendix A of RFC 7223. If I have a leafref path like "/if:interfaces/if:interface[name='at-0/0/0']/eth:duplex" then if 'at-0/0/0' isn't an Ethernet interface, it doesn't refer to any leaf node because "eth:duplex" is not valid for that particular path expression. Lada > > 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. > > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
