> On 08 Jun 2016, at 09:51, Martin Bjorklund <[email protected]> wrote: > > 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.' > > The text for "path" already says: > > It takes as an argument a > string that MUST refer to a leaf or leaf-list node.
It's unclear what "refer" means. If it's XPath, it can only refer to an instance in a data tree, not in the schema. Lada > > >> to the new text but I think the time has come to stop searching for >> new possible ways to misunderstand the specification. > > > /martin > > > >> >> 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 >> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
