Using metadata policy on metadata parameters with JSON object values

[Razumain]

While updating my implementation I was not very happy to see that objects have been added as optional metadata values for policy processing. I really think some guidance is necessary here.

In order to implement processing of metadata for parameters with object values, it will be necessary to implement object comparison, and this process should be described. Questions that comes to my mind is:

1. Does order of elements need to match?
2. Can any object structure be provided?
3. Is it a match if the metadata object contains all elements of the metadata policy, but also other additional elements?
4. Is there any difference if the operator is subset_of or superset_of with regard to comparison rules?

The big drawback with objects here is that it really does not fit the metadata policy methodology. The more complex JSON objects, the harder it will be to provide a sensible and useful policy. True Interoperability will be very hard to achieve.

I would personally much rather see policy processing to be limited to simple types. If you want to use policy, then you better define metadata parameters with simple types, as metadata traditionally is defined.

At least I would like to remove any mandatory implementation of policy processing with object values (today it is mandatory in add and default.

[selfissued]

I agree that simplicity is a virtue, including when applying metadata policies. This aligns with my comment #34 (comment), in which I posit that applying policies will be easier for simple data structures than hierarchical data structures.

[vdzhuvinov]

Thanks for this feedback Stefan. I will revisit the original considerations for this and will get back here.

[vdzhuvinov]

I consulted the JSON RFC and standards that use JSON for a language that must exhibit predictable behaviour, like JSON Path.

As long as the JSON, including JSON objects, regardless of complexity, are what the JSON RFC 8259 describes as "interoperable", the policies are going to be predictable and deterministic.

Non-interoperable JSON is for example JSON objects with duplicate member names.

Still, I recognised that some JSON libraries may have issues comparing JSON objects. For this reason, the JSON object support is specced as mandatory only for the value, default and essential operators, as they don't require any comparison. It is optional only for the add operator and the set / JSON array based operators.

Here is a PR to clarify this:

#168

[selfissued]

I propose to resolve this issue by adding this design rationale to the specification (from @vdzhuvinov's comment above):

Some JSON libraries may have issues comparing JSON objects. For this reason, the JSON object support is specified as mandatory only for the value, default and essential operators, as they don't require any comparison. It is optional only for the add operator and the set / JSON array based operators.