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). /js -- 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
