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. 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 > > 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 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod