> On 02 Jul 2015, at 22:08, Andy Bierman <[email protected]> wrote:
>
>
>
> On Wed, Jul 1, 2015 at 11:33 PM, Ladislav Lhotka <[email protected]> wrote:
> Andy Bierman <[email protected]> writes:
>
> > I agree with Juergen that the implementation of YANG constraints
> > on a datastore is not XML-specific. The text refers to data nodes
> > not XML elements. It is quite possible for a server to populate data
>
> The text says in sec. 6.4: "The data model used in the XPath expressions
> is the same as that used in XPath 1.0 [XPATH], …", and the data model in
> [XPATH] is about elements, attributes, namespaces etc. In order to
> correctly interpret [XPATH], one needs to map (conceptually, if you
> wish) the data tree onto the XPath data model.
>
> > nodes in a datastore without NETCONF of XML being involved.
>
> And what about RPCs and notifications? In this case the accessible data
> tree is defined as the corresponding XML instance document.
>
>
>
> There is no possibility for data to be converted between
> XML and JSON if this is the case.
I don’t know why, and it’s not about converting. Are you saying JSON encoding
of RPC operations is ill-defined?
>
>
> 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.
>
That’s not the point. The above XPath expression is perfectly valid so its
result should be deterministic and identical to "non-conceptual” XPath
evaluation.
Saying that all gaps in the spec are pathological examples is an extremely
slippery slope.
>
>
> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
> <foo xmlns="http://example.com/xtest";>
> <x>+1</x>
> <y>1</y>
> </foo>
> </rpc>
>
> And how about this RPC input in JSON?
>
> {
> "foorpc:input": {
> "x": +1,
> "y": "1"
> }
> }
>
> >
> > We keep getting stuck on the difference between resource representations
> > on the wire, and implementation details within a client or server.
>
> This is not my problem here.
>
>
>
> There are lots of XPath expressions that can be constructed
> that create problems because of the way XPath converts
> types by default. That is why there are functions number(), string(), etc.
Funny enough, 6087bis says:
The 'local-name', 'namespace-uri', 'name', 'string', and 'number'
functions SHOULD NOT be used if the argument is a node-set.
Lada
>
>
>
> Lada
>
> Andy
>
>
> > There is no requirement that they be the same "XML or JSON".
> > inside.
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
