Remove restrictions

[letmaik]

I see that the schema has "additionalProperties": false. Why is that the case? JSON is all about extensibility. Similarly, why is the "result" required to be exactly one of the defined types? I thought O&M's result type is Any.

[dr-shorthair]

Re additionalProperties:
This was to help with our development of the initial validation framework - too loose and we couldn't test the validation very effectively. I think the intention is to relax this in due course.

[dr-shorthair]

Re result type:
There is a tension here between flexibility and interoperability. It is easier on processors (including validators) if there is a known set of result objects. However, we would expect additional objects to be added.

Also, OM-JSON does not claim to fully implement O&M.

[peterataylor]

Yep exactly as Simon said - we needed it for the validation. I've added the
'super strict' mode to the schema lint tool, so we can probably now remove
from schema. Will do this.
On Sep 24, 2015 7:47 PM, "Simon Cox" [email protected] wrote:

Re additionalProperties:
This was to help with our development of the initial validation framework

• too loose and we couldn't test the validation very effectively. I think
  the intention is to relax this in due course.

—
Reply to this email directly or view it on GitHub
#2 (comment).

[letmaik]

About result type, I know that JSON Schema has limitations, but this shouldn't influence the format you develop. We were thinking of possibly using a later version of OM-JSON ourselves for big coverage data, where we would have as "result" something like that: https://github.com/Reading-eScience-Centre/coveragejson/blob/master/spec.md

[dr-shorthair]

If you develop a JSON-Schema representation of JSON Coverage we can easily add the necessary JSON-ref to the result model in OM-JSON (or you can fork of course).

[letmaik]

There shouldn't be a dependency from OM-JSON to outside schemas. That's
why I think "result" should be allowed to be anything. What you really
want to have are rules like "if the observation type is 'Measurement',
then 'result' must follow 'Common.json#/definitions/measure'" etc. If
none matches, it is still valid. The problem is that JSON Schema doesn't
let you express that. It's just not powerful enough. But as you defined
it currently, the schema is too restrictive, too closed. And since there
is no other specification of the JSON I take the schema as the
contractand nothing else. And other's will too and they will say "hm ok,
so I can only use the predefined observation types" and possibly leave
if those are not suitable.

On 24/09/2015 11:31, Simon Cox wrote:

If you develop a JSON-Schema representation of JSON Coverage we can
easily add the necessary JSON-ref to the result model in OM-JSON (or
you can fork of course).

—
Reply to this email directly or view it on GitHub
#2 (comment).