Re: [netmod] xpath expressions in JSON

[Andy Bierman <[e-mail]>]

On Fri, Oct 12, 2018 at 3:22 AM, Robert Wilton <[e-mail]> wrote:

> Hi Andy,
> On 11/10/2018 17:52, Andy Bierman wrote:
>
>
>
> On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton <[e-mail]> wrote:
>
>>
>> ....
>>
>>>
>>> Finally, I'm trying to figure out have RFC 8040 query parameter (sect
>>>> 4.8.4), which also uses XPath expressions is meant to work. That
>>>> states:
>>>>
>>>> The set of namespace declarations is the set of prefix and
>>>>        namespace pairs for all supported YANG modules, where the prefix
>>>>        is the YANG module name and the namespace is as defined by the
>>>>        "namespace" statement in the YANG module.
>>>>
>>> Perfect!  It seems the authors of 8040 thought of this ;-)
>>>
>> OK, what you propose would at least be consistent with how the XPath is
>> formed in sec 8040, 4.8.4?
>>
>> I can live with that.  But still strongly think that WG should think of
>> trying to move YANG on from Xpath 1.0.
>>
>
>
> I do not agree YANG should change any statements where XPath is being used.
> (Note that leafs like the filter are free to use whatever data type they
> want, including yang:xpath1.0).
>
>
> OK, I think that I would be proposing either doing this as part of
> YANG.next, or perhaps as different leaf types.
>
>
> The WG is on the right track already wrt/ XPath by creating custom XPath
> functions
> like 'deref' that simplify syntax or extend functionality.
>
>
> Yes, the functions partially help.
>
> But there are bits of Xpath expressions that are not meaningful for YANG
> (e.g. NodeType checks or processing-instruction).
>
> The fact that NodeSets are sets rather than sequences isn't particularly
> helpful (fixed in future versions of XPath).
>
> E.g. if I wanted to check that a particular YANG boolean leaf is true then
> I might write "enabled = true" ... which is valid XPath, but probably
> doesn't do what most people expect ...
> When they realize that is wrong, perhaps they will try "enabled = true()"
> instead ... which is also valid XPath, but still probably won't do what
> they expect ...
> Instead they have to do 'enabled = "true"'.
>
> And then what about comparisons for 64 bit numbers that don't work
> properly?
>
> So, it seems like there are quite a lots of gotchas when using XPath for
> YANG, and it is far from an ideal language for expressing configuration
> constraints.
>
> If YANG adoption increases, and if folks start putting more validation
> constrains into the model then I hope that we will end up with a better
> language for expressing those constraints.
>
>

There are parts of XPath that are not used and most people are unaware
XPath even has
those details. Not a real problem.

There is usually a high cost to pay for instability. IMO we have already
seen that with the churn
that NMDA has caused. Training people over again has a cost.  Confusing
people by having
6 or 7 different path language variants that mostly look the same has a
cost.

I guess we will have this debate for real if YANG 2.0 is ever done


Thanks,
> Rob
>
>
Andy


>
>
>
>
>>
>>> Yet the examples in section 8.3.6 don't seem to use namespace prefixes
>>>> in very many places, e.g. why is it "/example-mod:event1/name='joe'"
>>>> and not "/example-mod:event1/example-mod:name='joe'"?  Is the example
>>>> wrong, or otherwise what am I missing? :-)
>>>>
>>> It seems the example is wrong!
>>>
>> Please can you check section 8040, 8.3.6.  Are all the examples wrong?
>>
>> Thanks,
>> Rob
>>
>>
>>>
>>> /martin
>>> .
>>>
>>>
>>
>
> Andy
>
>
>