Revisit Endpoints and method definitions for OGC parsing

[roomthily]

The supported formats are listed as empty elements:

<GetFeature>
    <ResultFormat>
        <GML2/>
    </ResultFormat>

with two required (one for describefeature type and one for getfeature) but theoretically there could be more

[roomthily]

Seriously not making it easy:

<ows:Value>XMLSCHEMA</ows:Value>
<ows:Value>text/xml; subtype=gml/2.1.2</ows:Value>
<ows:Value>text/xml; subtype=gml/3.1.1</ows:Value>

with valid mimetypes and WxS controlled vocab terms (XMLSCHEMA).

[roomthily]

Thinking out loud:

We have Format elements in some of the older Capability/Request/{Method} elements. Those formats are tied to the Format query parameter. Some format values may be valid mimetypes; some may be a controlled vocabulary term (XMLSCHEMA, etc). A set of formats can contain both types.

In this older schema set, no other query parameter is defined through the GetCapabilities response. So the VERSION query param does not list supported versions (you have requested a version to get to that point anyway, it's not about the version of the specific response, it's about knowing what versions of the wms are available for request).

In the newer versions (standardizing on the OWS schema), the OperationsMetadata/Operation[name={method}]/Parameter elements contain some of the enumerations and are tagged with a name. Unfortunately, that name is not necessarily the query parameter key. As noted in the other comments, there are pre-defined terms and mimetypes mixed in those enumerations.

On the plus side, it does include the enumeration for supported versions on the GetCapabilities (not the other methods but I suspect without poking around the schemas, specs, that it is "inherited" by the other children.

[roomthily]

Also, constraints:

<ows:Constraint name="DefaultMaxFeatures">
    <ows:Value>1000</ows:Value>
</ows:Constraint>

[roomthily]

Current thinking on a config structure for the parameter mappings (OGC or OWS, that is a code issue rather than a definition issue):

{
  // service-type and version
  "WFS-1.1.0": {
    // method
    "GetCapabilities": {
      // query parameter name from the spec
      "Version": {
        // format of the parameter value, if not simple text blob
        "Format": "",
        // parameter type (this is based off the opensearch structure
        // and may not be required here)
        "Type": "",
        // fully qualified namespace
        "Namespace": "",
        // prefix for the namespace
        "Prefix": "",
        // is the parameter required? boolean
        "Required": true,
        // for those parameters that include some enumeration in the 
        // response, provide a mapping between the spec name and the 
        // tag in the response (Format == outputFormat), whether it
        // will have an enumeration (no assumptions!), and, if that enumeration
        // has any kind of controlled vocab terms, a mapping between the
        // term and its value
        "Remap": {
          // name of the parameter used in the response
          "remapped": "",
          // boolean for the enumeration
          "can_have_values": true,
          // handle the controlled vocab terms as 
          // "VALUE IN RESPONSE": "actual value"
          "value_remaps": {
            "XMLSCHEMA": "text/xml"
          }
        }
      }
    }
  }
}

with method and parameter names upper case.

[roomthily]

I am not sure what the WFS GetFeature 1.1.0 resultType parameter refers to.

[roomthily]

I am doing a quick run through the harvested services to prioritize the service/version sets to configure.

Note: you can't, by the way, rely on the format in the URL (FORMAT=x.x.x) or the version in the namespace to identify the WxS version.

[roomthily]

Prioritized list of WxS Response Versions to add to the configurations:

• WFS 1.0.0
• WFS 1.1.0
• WMS 1.3.0
• WCS 1.0.0
• WCS 1.1.2

[roomthily]

And for version identification, never forget: ows:ServiceTypeVersion is not a singleton and should not be used for identifying the version. Note also that the WCS is not as standard for the OWS namespaced version with the root node as Capabilities instead of the WxS_Capabilties structure.

See response for an example.