Closed bquinn closed 2 years ago
@iyoung @jolla56 please check and see if this accurately reflects our discussion today...?
Yes it does, I did some more testing today because I was afraid that adding geojson as in alternative 1 would force the mandatory properties in geojson, but it seems to be ok. You could further show that, even if we do not suggest such usage, the construction in alt 1 could lead to instances like this:
"places": [ { "name": "London, UK", "rel": "mentioned" }, { "name": "Paris, France", "rel": "describes", "type": "Polygon", "coordinates": [0.0, 0.1, 0.2, 0.3] }, { "type": "Point", "coordinates": [1.45,3.67] } ]
But it then become unclear what the last point refers to.
Alternative 2 could be as confusing if not used properly because we do not require any of the first four properties in the place object:
"places": [ { "name": "London, UK", "rel": "mentioned" }, { "name": "Paris, France", "rel": "describes", "geojson": { "type": "Polygon", "coordinates": [0.0, 0.1, 0.2, 0.3] } }, { "geojson": { "type": "Point", "coordinates": [1.45,3.67] } } ]
fixed in #128
We have a problem with ninjs 2.0 whereby the geojson validation doesn't work properly.
Currently we set additionalProperties in the wrong place here:
Because this additionalProperties line is set in the wrong place, it means that any property is allowed in a "places" object.
We have two options:
Option 1: We can add
additionalProperties: true
in the place indicated above, which would allow geoJSON properties to be inter-mixed with the defined name, rel, uri and literal properties that we define in the schema.So a valid instance would look like this:
Pros:
Option 2: Add a new property as a child in the
places
array objectSo the schema would look like this:
Pros:
Cons:
Related issues that don't directly affect the decision above: