Operating System: Linux
Platform: PC

https://git.opendaylight.org/gerrit/#/c/8280/

1. case
container schema node + multiple data nodes for container -> RestconfDocumentedException with error tag bad-element which is mapped to return code 400

2. case
list schema node + single data node -> valid case regardles if it is specified in json:
-> incorrectly as container
"list-name":

-> correctly as list
"list-name": [{},{}...,{}]

3 Remarks from Tom Pantelis. 2 of them were incorporated. 1 requires more clarification.

Patch set 3 was comitted
https://git.opendaylight.org/gerrit/#/c/8280

I noted https://git.opendaylight.org/gerrit/#/c/8280 with my test findings.

I reproduced the issue by adding the following to the toaster's make-toast input:

container ero {
list sub {
leaf lf

}
}

then sending payload:

{
"input" :
{
"toaster:toasterDoneness" : "3",
"toaster:toasterToastType":"wheat-bread",

"ero":
[
{
"sub" :

,
"sub" :

}
]
}
}

The RPC will succeed but in the output from the toaster you will only see 1 of the "sub" elements.

I also tested make-toast passing in 2 "ero" elements:

{
"input" :
{
"toaster:toasterDoneness" : "3",
"toaster:toasterToastType":"wheat-bread",

"ero": {
"sub" :
[

]
},

"ero": {
"sub" :
[

]
}
}
}

and it succeeded but only the last "ero" element was taken.

In fact this seems to be a general problem with any type of json element, even leafs. This also succeeds:

{
"input" :

}

The toaster got called with "frozen-waffle".

The google JsonParser is lenient with allowing duplicate elements with the same name. It internally stores the elements in a map by name so it weeds out duplicates (last one in wins).

I tried the input above with a few on-line validators. 2 of them said it was valid (JSONLint and http://jsonformatter.curiousconcept.com/). But the one at http://www.freeformatter.com/json-validator.html said the

"input is NOT valid according to RFC 4627 (JSON specification). Unexpected duplicate key:toaster:toasterToastType".

But it also said it was valid in JavaScript.

So it seems it's up to the json parser whether or not it is strictly compliant with the JSON spec with respect to duplicate elements.

I didn't see any setting in the JsonParser to configure it to be strict. Maybe there's a way to hook into it to enforce key uniqueness. Other than that, if we want to address this issue, we may have to explore other parsers that are more strict.

Good analysis Tom,
yes your input

{
"input" :

}

is valid Javascript, but "maybe-invalid" JSON, RPC for JSON states:

2.2. Objects

...
The names within an object SHOULD be unique.
...

That's why also existing external tooling is confused about whether this is valid JSON or not and probably most implementations opted for Javascript semantics - latest value wins.

I would go with behaviour that duplicate is error, because default behaviour of GSon hides potential bug in user input.

> So it seems it's up to the json parser whether or not it is strictly compliant with the JSON spec with respect to duplicate elements.

True. There are even more obvious semantic questions. For example, is order of elements in JSON array important, or could elements be re-ordered arbitrarily? Answer: It depends on the Yang model definition, specifically whether "order-by user;" is present. (This affects testing, in analyzing response.)

What we are dealing with is not just JSON syntax, but also "Content-Type:application/yang.data+json" semantics, which is just being defined as we run into corner cases. Ideally, we should have a wiki page tracking details like "list schema node + single data node -> valid case regardles if it is specified in json".

I mean, it is probably not worth to spend developer time to make JSON handling as close to RFC intentions as possible; user frienliness is more important. In this case, friendliness is a balance between strict error checking and sane error correction.

(In reply to Vratko Polák from comment #6)
> I mean, it is probably not worth to spend developer time to make JSON
> handling as close to RFC intentions as possible; user frienliness is more
> important. In this case, friendliness is a balance between strict error
> checking and sane error correction.

The problem is that the silent error correction wrt duplicates is ambiguous. In the make-toast input, did I really mean "wheat-toast" or "frozen-waffle"? In this case I don't mind either for breakfast but in real, critical situations, we shouldn't have ODL potentially guessing what the user really intends semantically. So I agree with Tony that we should be strict wrt to duplicates.

Syntactically I think we can be more user-friendly and not be strictly compliant. Eg, in the JSON spec, each element name has to be in double-quotes but most parsers are probably lenient about this (gson is, except if the name contains a yang prefix with ':').

@Tom
can you advise some JSON parser which checks uniqueness of names in JSON object?
Thanks

(In reply to Jozef Gloncak from comment #8)
> @Tom
> can you advise some JSON parser which checks uniqueness of names in JSON
> object?
> Thanks

I haven't investigated other parsers. Try googling - there's probably other free/open-source parsers out there.

Another option is to change the gson parser to add a flag to disallow duplicates, either by filing a request with Google or contributing a change ourselves if it's open-source.

Currently the case when not unique key name in JSON object occurs is caught. In such a case RestconfDocumentatedException is raised.
https://git.opendaylight.org/gerrit/#/c/8280/

draft
https://git.opendaylight.org/gerrit/#/c/8557/

gson code was changed and added to opendaylight
JSON file is now parsed only once.

gson framework - https://git.opendaylight.org/gerrit/#/c/8559
CONTROLLER-559 - exception if multiple container node occures - https://git.opendaylight.org/gerrit/#/c/8561/

gson code was changed and added to opendaylight
JSON file is now parsed only once.

JsonParser was implemented as was advised by Tom Pantelis.
Current patch set 7
https://git.opendaylight.org/gerrit/#/c/8280/

patch set 8 uploaded
https://git.opendaylight.org/gerrit/#/c/8280/

> I would expect to get error code 400

I have verified that my expectation is met now.