On 2016-06-08 09:48, Martin Bjorklund wrote:
> Andy Bierman <a...@yumaworks.com> wrote:
>> On Tue, Jun 7, 2016 at 9:38 AM, Juergen Schoenwaelder <
>> j.schoenwael...@jacobs-university.de> wrote:
>>
>>> On Tue, Jun 07, 2016 at 09:08:56AM -0700, Andy Bierman wrote:
>>>> 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.
>>>>
>>>
>>> It says 'in the schema tree' so I think there is no problem. We were
>>> discussing the corner case where the path argument does not point to a
>>> schema node at all. Pyang already reports this as an error (bar in the
>>> path of foo [...] is not found).
>>>
>>>
>> I thought the original issue was that the ABNF does not support
>> position-based
>> instance identifiers.
>
> This is supported even in RFC 6020.
But not for the leafref 'path' argument, right? I'm not sure how
instance-identifier values are relevant in this particular discussion...
--Per
> /martin
>
>
>> In the rare event that the i-i pointed to a
>> config=false
>> list entry (with no keys defined) then its position needs to be used.
>>
>> I thought it was clear that the path-stmt has to point at a schema node
>> that can be resolved in the module context using the import-stmts.
>>
>>
>>
>>> /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
