On Tue, Jun 7, 2016 at 9:38 AM, Juergen Schoenwaelder < [email protected]> 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 < > > [email protected]> wrote: > > > > > On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote: > > > > Ladislav Lhotka <[email protected]> writes: > > > > > "Dale R. Worley" <[email protected]> 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. 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
