Ladislav Lhotka <[email protected]> wrote:
>
> > On 24 May 2016, at 12:04, Martin Bjorklund <[email protected]> wrote:
> >
> > Ladislav Lhotka <[email protected]> wrote:
> >>
> >>> 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.
> >
> > Note that is a very restricted XPath expression. The key values are
> > only used in predicates, and the predicates don't affect the location
> > path.
>
> But the one below is valid, right?
Yes.
> You have always insisted that
> schema nodes for which "when" expression evaluates to false are not
> part of the schema
I don't think I used that wording...
> which means that different entries of the same
> list may have different schemas, and predicates then affect the
> location path - "if:interface" is an example.
>
> >
> >>>> 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.
> >
> > Correct, so the value space would be the value space of eth:duplex.
> > The additional constraint would always evaluate to false if there is
> > never an interface 'at-0/0/0'.
>
> There can be one:
>
> "interface": {
> "name": "at-0/0/0",
> "type": "ianaift:atm",
> ...
> }
>
> According to sec. 7.21.5, the leaf node "eth:duplex" is invalid in
> this entry, so it makes no sense to talk about its value space.
I don't agree that "when" or "if-feature" removes nodes from the
*schema*. The text says that they make these nodes invalid (scoped to
the parent).
So, imo, eth:duplex does exist in the schema (but will be invalid in
this case).
/martin
>
> Lada
>
> >
> >
> > /martin
> >
> >
> >
> >>
> >> 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
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
