search

opengeospatial / ogcapi-features

An open standard for querying geospatial information on the web.
https://ogcapi.ogc.org/features
Other
342 stars 85 forks source link

XML for the Common resources (originally for Part 2) #397

Open cportele opened 4 years ago

cportele commented 4 years ago

Part 2 adds additional information to the Collections and Collection resources (the available CRSs, the storage CRS and its coordinate epoch).

For the JSON or a YAML encoding the OpenAPI schema fragments specify how the information is added to the resources. For HTML the only requirement is that the information is included in the HTML body.

The only encoding that would require additional specification would be the XML encoding. The content model of the core:CollectionsType and core:CollectionType would need to be extended (in another namespace) or at least be made extendable (with any elements).

In the 2020-05-25 meeting we decided to not add anything in Part 2 for the XML encoding of the Collections and Collection resources. The reasoning is this:

As far as we can tell, there is only minimal, if any, uptake and use of the XML encoding for the Common resources (landing page, conformance declaration, collections, collection) in clients. Given that supporting proper extensions to the XML content types adds complexity to the specification and to implementations (due to the way XML schemas and namespaces work), such requirements should only be added, if it is clear that there is sufficient demand for this. Adding something just for completeness is an anti-pattern.

Also, no concerns about the lack of XML support have been raised so far, including in the public review.

We plan to take a decision in the next SWG meeting on 2020-06-08, so if you have any comments or concerns, please raise them now.

PS: Since this is a general topic, it could also be considered to deprecate the XML support for these four resources in a future version of Part 1 and focus only on the JSON and HTML encodings for navigating the API. Note that is separate from support for GML as a feature encoding, which would not be affected.

pvretano commented 4 years ago

@cportele As discussed in the teleconference today, the XML support was added to Part 1 as a transitional step for those migrating from XML. The idea was that developer could implement the new API and still use a lot of the XML generation code they had developed for the WFS. As it is clear that the uptake of XML for the common resources is weak, we should consider deprecating the XML support in the next version of the Part 1. As for Part 2 (or X), I agree, lets not support XML until we have some/any indication that people are using XML. Adding it just for completeness is, as you have said, an anti-pattern! Does OGC API - Common include XML encodings? If so, we might consider cross linking this issue so that they can consider removing XML support since it seems to be more of a headache to maintain than its uptake justifies.

cportele commented 4 years ago

I just had a look. The Common drafts only support JSON and HTML, so this is consistent.

cportele commented 4 years ago

Resolved for Part 2, moved to the Part 1 project for discussion in a future revision that is not a corrigendum.