> On 27 May 2016, at 19:30, t.petch <[email protected]> wrote: > > > ----- Original Message ----- > From: "Martin Bjorklund" <[email protected]> > To: <[email protected]> > Sent: Monday, May 23, 2016 3:10 PM >> >> This comment from the Gen-ART review deserves it's own thread. >> >> gen-art> - section 9.9 >> gen-art> >> gen-art> The leafref type is used to declare a constraint on the > value space >> gen-art> of a leaf, based on a reference to a set of leaf instances > in the >> gen-art> data tree. The "path" substatement (Section 9.9.2) > selects a set of >> gen-art> leaf instances, and the leafref value space is the set of > values of >> gen-art> these leaf instances. >> gen-art> >> gen-art> The first sentence isn't quite right. Perhaps: >> gen-art> >> gen-art> The value space of a leaf with leafref type is one of the > values of >> gen-art> a set of leaf instances in the data tree. The "path" > substatement >> gen-art> (Section 9.9.2) selects the set of leaf instances, and the > leafref >> gen-art> value space is the set of values of these leaf instances. >> gen-art> >> gen-art> - section 9.9.3 >> gen-art> >> gen-art> If "require-instance" is "true", it means that the > instance being >> gen-art> referred MUST exist for the data to be valid. This > constraint is >> gen-art> enforced according to the rules in Section 8. >> gen-art> >> gen-art> If "require-instance" is "false", it means that the > instance being >> gen-art> referred MAY exist in valid data. >> gen-art> >> [...] >> gen-art> Also, I think the second paragraph means that if > require-instance is >> gen-art> false, the referred-to instance need not exist. But it's not > clear to >> gen-art> me what that would mean -- if there are no instances > referenced by the >> gen-art> XPath expression, then the set of value values of the leafref > would be >> gen-art> empty and the leafref would necessarily be invalid. ... I > think these >> gen-art> paragraphs need to be expanded in some way. >> >> mbj> Right; so what we want to say is: >> mbj> >> mbj> - the value space is the same as the value space of the > referred >> mbj> leaf >> mbj> >> mbj> - there is an additional constraint if require-instance is true > that >> mbj> the referred to leaf instance must exist >> mbj> >> mbj> How about >> mbj> >> mbj> OLD: >> mbj> >> mbj> The leafref type is used to declare a constraint on the value > space >> mbj> of a leaf, based on a reference to a set of leaf instances in > the >> mbj> data tree. The "path" substatement (Section 9.9.2) selects a > set of >> mbj> leaf instances, and the leafref value space is the set of > values of >> mbj> these leaf instances. >> mbj> >> mbj> If the leaf with the leafref type represents configuration > data, and >> mbj> the "require-instance" property (Section 9.9.3) is "true", the > leaf >> mbj> it refers to MUST also represent configuration. Such a leaf > puts a >> mbj> constraint on valid data. All such nodes MUST reference > existing >> mbj> leaf instances or leafs with default values in use (see > Section 7.6.1 >> mbj> and Section 7.7.2) for the data to be valid. This constraint > is >> mbj> enforced according to the rules in Section 8. >> mbj> >> mbj> NEW: >> mbj> >> mbj> The leafref type is used to declare a constraint on the value > space >> mbj> of a leaf, based on a reference to a set of leaf instances in > the >> mbj> data tree. The "path" substatement (Section 9.9.2) is used to > refer >> mbj> to another leaf node. The leafref value space is the value > space of >> mbj> this leaf node. >> mbj> >> mbj> If the "require-instance" property is "true", there MUST exist > an >> mbj> instance, or a leaf with a default value in use (see Section > 7.6.1 >> mbj> and Section 7.7.2), of the leaf being referred to with the > same value >> mbj> as the leafref value in a valid data tree. >> mbj> >> mbj> If the leaf with the leafref type represents configuration > data, and >> mbj> the "require-instance" property (Section 9.9.3) is "true", the > leaf >> mbj> it refers to MUST also represent configuration. >> >> Does anyone have comments on this proposal? > > yes! > > I realise that the discussion is moving on, and corner cases are > appearing, but I think that the NEW paragraph is still a tough read. I > rearrange the words - more or less -and get > > NEW > > The leafref type is used to declare a constraint on the value space of a > leaf. > > The "path" substatement (Section 9.9.2) which MUST be present references > another leaf node. The value space of this other leaf node defines a set > of values, which may be empty (e.g. when the leaf node is not present in > the data tree). > > If the "require-instance" property is "true", then the value of the leaf > with the leafref type MUST exist in the set of values; the set of value > includes leafs with have a default value in use (see Section 7.6.1 and > Section 7.7.2)
I think this not correct. Unlike RFC 6020, the "path" argument is now used for two different purposes: 1. It is evaluated as an XPath expression against an instance document (datastore), which results in a node set. If "require-instance" is true, then at least one node in that node set must have the same value as the leaf with leafref type. This is the original 6020 meaning. 2. It also implicitly refers to a leaf node in the schema, and the *type* of this other leaf node determines the type and set of valid values for the leaf with learef type. This is independent of the "require-instance" value and any datastore content. However, any semantic constraints that may apply to the other leaf (such as "must" statements) are not taken into account. Lada > > If the leaf with the leafref type represents configuration data, and > the "require-instance" property (Section 9.9.3) is "true", then the > target of the "path" substatement MUST also represent configuration > data. > > Tom Petch > >> /martin >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
