> On 07 Jun 2016, at 18:45, Andy Bierman <a...@yumaworks.com> wrote:
>
>
>
> On Tue, Jun 7, 2016 at 9:38 AM, Juergen Schoenwaelder
> <j.schoenwael...@jacobs-university.de> wrote:
> On Tue, Jun 07, 2016 at 09:08:56AM -0700, Andy Bierman wrote:
> > On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > > On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote:
> > > > Ladislav Lhotka <lho...@nic.cz> writes:
> > > > > "Dale R. Worley" <wor...@ariadne.com> writes:
> > > > >> A difficulty I have with the current wording is that it doesn't point
> > > > >> out the crucial fact about leafref that the XPath expression can only
> > > > >> select elements that are instantiations of one particular data node.
> > > I
> > > > >> don't know XPath, but it seems that that is not a general property of
> > > > >> XPath expressions, you seem to be able to write XPath expressions
> > > > >> that
> > > > >> select heterogenous groups of elements. So it's worth pointing out
> > > that
> > > > >> the allowed XPath expressions can't do that, and that is because of
> > > the
> > > > >> restriction that the expression must match path-arg.
> > > > >
> > > > > Right, this is the slightly hand-waving part that I also objected to.
> > > An
> > > > > XPath expression in a leafref's "path" statement indeed selects a node
> > > > > set from an instance data tree. The node seet can be empty, but if it
> > > is
> > > > > non-empty, all its members necessarily have the same type, which is
> > > > > defined in a certain "leaf" schema node.
> > > > >
> > > > > The relationship is relatively straightforward but difficult to
> > > > > explain
> > > > > concisely. One basically has to follow the steps in the XPath
> > > > > expression, ignore all path-predicates, and skip all schema nodes that
> > > > > aren't data nodes (i.e., "choice" and "case" nodes).
> > > >
> > > > Yes, it's difficult to explain, though once one gets the idea, it's
> > > > straightforward enough. The problem I have is that it's not pointed out
> > > > explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I don't
> > > > see it there.)
> > > >
> > > > The crucial points seem to be:
> > > >
> > > > - The XPath expression is limited by the syntax "path-arg" and the rules
> > > > in 9.9.2.
> > > >
> > > > - Because of those restrictions, there exists one data node in the
> > > > schema such that: evalutating the expression for any leaf or
> > > > leaf-list node in any data tree returns a set of nodes, all of which
> > > > are instances of that one schema node.
> > > >
> > > > - The type of that schema node is the base type of the leafref.
> > > >
> > > > - Once you learn this, it's easy to see, for any particular
> > > > leaf/leaf-list node and path expression in a module, which schema node
> > > > is the one. But it's rather hard to describe that process.
> > > >
> > > > Actually, there's an ugly question: If the path expression references
> > > > an element name that doesn't exist in the module. Perhaps there are
> > > > rules in XPath that prevent it, but it seems to me that you could write
> > > >
> > > > leaf mgmt-interface {
> > > > mandatory false;
> > > > type leafref {
> > > > path "../interface/name";
> > > > require-instance true;
> > > > }
> > > > }
> > > >
> > > > when the current module doesn't have a "name" child defined for
> > > > "interface". As long as a data tree didn't contain a mgmt-interface
> > > > elememt, the constraint would not be violated.
> > > >
> > > > But a later revision of the module, the "name" child could be added,
> > > > allowing data trees to contain mgmt-interface elements, because data
> > > > trees could now have "name" elements.
> > > >
> > > > The point being that when you're figuring out which schema node is the
> > > > base type for the leafref, that schema node has to exist so the base
> > > > type can be extracted. But there's no direct statement of that as a
> > > > requirement for path validity.
> > > >
> > >
> > > As WG chair, I am getting a bit nervous. We have to wrap things up and
> > > we need deliver the specification - it is past WG last call, it is
> > > past IETF last call, it is past IESG approval (kind of). We can likely
> > > endlessly continue to search for possible ways to misunderstand the
> > > specification but lets remember the aphorism 'perfect is the enemy of
> > > good'.
> > >
> > > I leave it to Martin's discretion to decide whether he wants to add
> > > 'The referred leaf or leaf-list node in the schema tree MUST exist.'
> > > to the new text but I think the time has come to stop searching for
> > > new possible ways to misunderstand the specification.
> > >
> > >
> >
> > Doesn't the text above exclude a default leaf or leaf-list from the
> > value space? That would be incorrect.
> >
>
> It says 'in the schema tree' so I think there is no problem. We were
> discussing the corner case where the path argument does not point to a
> schema node at all. Pyang already reports this as an error (bar in the
> path of foo [...] is not found).
>
>
> I thought the original issue was that the ABNF does not support position-based
> instance identifiers. In the rare event that the i-i pointed to a
> config=false
> list entry (with no keys defined) then its position needs to be used.
A more significant change was the addition of the "require-instance"
substatement to the leafref type.
>
> I thought it was clear that the path-stmt has to point at a schema node
> that can be resolved in the module context using the import-stmts.
An example:
container top {
leaf foo {
type string;
}
container subtop {
choice choi {
leaf foo {
type uint8;
}
case barcase {
leaf bar {
type leafref {
path "../../foo";
}
}
}
}
}
}
Which of the two "foo" leaf nodes does the path argument point at? If the path
is interpreted in the schema tree, it may appear it is the one inside the
choice. Yes, we all know it points at the other one, but will all readers of
the spec come to the same conclusion?
Lada
>
>
> /js
>
>
> Andy
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
