XML for the Common resources (originally for Part 2)

Start with the Part 2 discussion of the Collections and Collection resources, especially the core:CollectionsType and core:CollectionType content models and their XML extension constraints. Review the stated decision context and the separate note about Part 1 XML support; done would require a resolved specification decision, but the issue does not identify an implementation file or concrete change.

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.