Re: [netmod] xpath expressions in JSON

[Robert Wilton <[e-mail]>]

Hi Andy,

On 11/10/2018 17:52, Andy Bierman wrote:
>
>
> On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton <[e-mail] 
> <mailto:[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.

Thanks,
Rob


>
>
>
>
>             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
>