Hi Andy,
On 11/10/2018 17:52, Andy Bierman wrote:
On Thu, Oct 11, 2018 at 9:45 AM, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> 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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
