search

opengeospatial / ogcapi-3d-geovolumes

5 stars 3 forks source link

OpenAPI definition of Content Type does not match the standard draft #10

Open mrossk opened 2 years ago

mrossk commented 2 years ago

The enumeration given for the Content Type in the OpenAPI definition document does not match to standards draft document part 8. MEDIA TYPES FOR ANY DATA ENCODING(S)

Both the draft standard and the examples specify application/json+3dtiles and application/json+i3s. The enumeration in the draft OpenAPI definition declares application/json-3dtiles and application/json-i3s. Instead of editing the additional pattern, it could be omitted, since an enumeration already excludes all other types.

https://github.com/opengeospatial/ogcapi-3d-geovolumes/blob/9ccc8492e909e460f4027c5f296602f1f9abb7f7/standard/openapi/ogcapi-3d-geovolumes-draft-0.0.2.yaml#L741-L750

cportele commented 2 years ago

The use of 'application/json-3dtiles' and 'application/json-i3s' as media types is not correct. These media types are not registered with IANA.

In the case of 3D Tiles this also is in conflict with the use of 'application/json' in the 3D Tiles 1.1 draft specification.

jerstlouis commented 2 years ago

@cportele The intent was to register them, but that should also be aligned with the 3D Tiles specification.

cportele commented 2 years ago

... and of course the i3s specification, too. Both are community standards and before thinking about registering media types this should be discussed with the owners of the specifications. Until then we should use 'application/json'.

The media type definitions may also need more work. For example, would the 3D Tiles media type also apply to the subtree JSON documents, would that be 'application/json' or another media type?

jerstlouis commented 2 years ago

@cportele

Until then we should use 'application/json'.

Well clients really needed a provisional way to know which links to follow (the i3s or the 3D Tiles BVH), which is why we used application/json+3dtiles, knowing that this would need to be resolved (involving the community) prior to the GeoVolumes specification becoming a standard.

There is nothing else in the link that would have allowed to distinguish 3D Tiles from i3s, since in both cases the "Bounding Volume Hierarchy" rel (http://www.opengis.net/def/rel/ogc/1.0/bvh) was used.

For example, would the 3D Tiles media type also apply to the subtree JSON documents, would that be 'application/json' or another media type?

I think that should be consistent.