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. I like to see all issues closed by the end of the week a new revision with all changes posted. People can then check the edits to be sure nothing broke and then the document should move via Benoit into the RFC editor queue by the end of the following week or Monday June 20th. /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
