Part 5: x-ogc-propertySeq seems useless?

[m-mohr]

What's the purpose of x-ogc-propertySeq? Can it actually be enfored? I see it provided for object properties, but objects in JSON have no order as per the JSON specification. I don't see how this could be implemented and would argue that it should actually be removed.

[cportele]

For data encoded in JSON this is irrelevant (and cannot be enforced), but for other representations (e.g., CSV or FlatGeobuf) the order is essential.

[cportele]

Meeting 2024-08-26: Currently, the document states "For cases, where the properties of the data have to be ordered in some representations of the data, the sequence of the properties can be expressed using a keyword x-ogc-propertySeq." We will add a note that provides examples and more context. That should address the issue.

[m-mohr]

In my opinion, it's a - sorry - bad imitation of an array. If something has an order, it should be an array.
In an object, it needs to be ensured that all subschemas have a number and that they are unique. What happens if only a subset of property schemas have x-ogc-propertySeq?
The spec also doesn't say (afaik) how the relation to patternProperties and additionalProperties are. Are these not allowed if x-ogc-propertySeq is used? What happens if I combine different schemas (oneOf, anyOf, etc.)?
This becomes especially important when specs then define wildcard properties such as Coverages with e.g. properties=B03,*
For this I need to resolve all this in utterly complex code that tries to handle all cases.
(Generally, it feels like the use of JSON Schema here is not appropriate, which is underlined by all the x-ogc- properties that are needed to solve all the usecases => #945 )

For data encoded in JSON this is irrelevant (and cannot be enforced), but for other representations (e.g., CSV or FlatGeobuf) the order is essential.

I don't quite get the order in CSV/FlatGeoBuf. Aren't these formats usually supporting field names? It seems much better to identify columns by name rather than by order.

[jerstlouis]

@m-mohr In GeoTIFF for example there is no way to describe or name the bands.
Whereas GeoTIFF 2.0 might fix that, this provides a solution that works right now.

[m-mohr]

I'm not sure I understand how this is relevant to my comment. Was this meant to be a comment towards my last sentence?

It seems much better to identify columns by name rather than by order.

(Note: GeoTiff is a raster format, but Features is not a raster API...)

[jerstlouis]

@m-mohr Yes, the concept of logical schemas are relevant to both feature collections and raster / gridded coverage data, and this is parat of the "common" aspects of this Schemas Part 5.

The use case is also relevant to formats like CSV / FlatGeoBuf which might not have field names.
(I guess for CSV it depends whether you use a header row or not?)

[cportele]

@m-mohr

If something has an order, it should be an array.

The properties in a JSON Schema of an object are not an array, so we need a mechanism to state an order for those representations that need one.

The spec also doesn't say (afaik) how the relation to patternProperties and additionalProperties are. Are these not allowed if x-ogc-propertySeq is used? What happens if I combine different schemas (oneOf, anyOf, etc.)?

You are correct, there is no statement. I think we should state that the relative position of properties described by additionalProperties or patternProperties is undefined. Maybe also state that all properties without an explicit position should be after all properties with an explicit position (i.e., a recommendation)?

Generally, it feels like the use of JSON Schema here is not appropriate, which is underlined by all the x-ogc- properties that are needed to solve all the usecases

The alternative would be to come up with our own tailored schema language. I do not see how this would be better. Using the well-known JSON Schema and extending it in just a few places is preferable in my view.

[m-mohr]

Yes, I'm worried about using JSON Schema for everything. JSON Schema is meant for JSON validation, but it's getting pressed into all kinds of use cases now, many of which have absolutely nothing to do with JSON. For example, in Coverages it's used to describe physical phenomena, that's just wrong IMHO. If you (often) end up with just type + various x-ogc- properties, then it's not really JSON Schema anymore anyway. Then it's a custom language that partially looks like JSON Schema.

It makes sense where data is provided as JSON, e.g. Queryables. But Coverages for example is stretching it too far and I'm not sure where else this may also be the case.