> On 07 Jun 2016, at 17:26, Dale R. Worley <wor...@ariadne.com> 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.
Yes, this is correct.
>
> 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
Actually, no, such an XPath is perfectly okay, it will just evaluate to an
empty node set, exactly as if the schema node exists but there is no instance
in the data tree - XPath just doesn't care about schemas.
>
> 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.
Hmm, I think you are right. Practically speaking, I would expect all YANG
module compilers to complain about nonexistent schema node, but it follows
neither from the old nor the new text.
>
> 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.
I guess a honest way out of this problem would be to describe how to get the
corresponding schema node from the path expression, and state that it must
always exist. This can't be done in one line or two though.
Lada
> Dale
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
