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.
This is supported even in RFC 6020.
/martin
> 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.
>
> 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.
>
>
>
> > /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/>
> >
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
