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.
Dale
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
