On Sat, Jul 04, 2015 at 08:32:04AM +0200, Ladislav Lhotka wrote:
>
> >
> > Consider this definition:
> >
> > rpc foo {
> > input {
> > leaf x {
> > type uint8;
> > must ". = ../y";
> > }
> > leaf y {
> > type string;
> > }
> > }
> > }
> >
> > Then what's the result of conceptual XPath evaluation for this RPC
> > request?
> >
> > Just because you can construct a pathological
> > case comparing strings and numbers doesn't
> > mean anything.
>
> Pathological?? Don’t forget that uint64 numbers are encoded as strings in
> JSON. Moreover, comparisons of two nodesets are *always* performed on string
> values, even if both have numeric types in YANG.
>
> >
> > Use "number(foo) < number(bar)" to ensure that
> > numeric comparisons are done correctly.
> >
If this +1 != "1" needs fixing, I think it needs fixing in the YANG
specification. For datastores, things are kind of handled since RFC
6020 says:
Note that since all leaf values in the data tree are conceptually
stored in their canonical form (see Sections 7.6 and 7.7), any XPath
comparisons are done on the canonical value.
For notifications, this is kind of handled as well:
When a NETCONF server sends data, it MUST be in the canonical form.
And of course, we expect the server to only send notifcations that are
valid anyway.
For RPCs, the obvious things to do would be to require that XPATH
evaluation of RPC arguments also takes place on the canonical
representation of values.
/js
--
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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
