b-cube / semantics-preprocessing

initial text preprocessors for the triplestore and feature classification
Other
2 stars 3 forks source link

Revisit Endpoints and method definitions for OGC parsing #7

Closed roomthily closed 9 years ago

roomthily commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

Also, constraints:

<ows:Constraint name="DefaultMaxFeatures">
    <ows:Value>1000</ows:Value>
</ows:Constraint>
roomthily commented 9 years ago

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 commented 9 years ago

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

roomthily commented 9 years ago

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 commented 9 years ago

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

roomthily commented 9 years ago

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.