On Fri, Oct 12, 2018 at 3:22 AM, Robert Wilton <rwil...@cisco.com> wrote:
> 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> 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 > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
