-
Notifications
You must be signed in to change notification settings - Fork 6
Specs
This page identifies possible issues (errors, ambiguities, etc.) in the relevant specifications that affect implementation or test development. These can be regarded as candidate change requests.
- OGC 12-176r5: OGC Catalogue Services 3.0 Specification - HTTP Protocol Binding
The "autodiscovery" facility in OpenSearch recommends inserting link elements into search results, but this is not what is described in 6.5.6.2. Instead, it inserts a link in the capabilities document using an ill-suited ows:Contraint element in the context of the GetRecords operation. It would be much better to just follow the OpenSearch spec here by adding an atom:link element so OpenSearch clients can easily find it just as if it occurred in search results (//atom:link[@rel="search"]) as suggested in the OS 1.1 spec.
<ExtendedCapabilities xmlns="http://www.opengis.net/ows/2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<atom:link rel="search"
href="http://example.com/csw/opensearch"
type="application/opensearchdescription+xml"
title="CSW 3.0 service" />
</ExtendedCapabilities> A base URL is defined as a "URL prefix to which parameters are appended to form a valid request" (4.1).
However, this is not necessarily distinct--there is one for every implemented service request that accepts a GET request. So "the" base URL mentioned in Requirement-008 is ambiguous; since it occurs in the context of obtaining service metadata, the relevant base URL is taken to be the one corresponding to the (mandatory) GET method binding for the GetCapabilities request.
Requirement-021 ascribes the media type "application/opensearchdescription+xml" to OpenSearch description documents, but this conflicts with Requirement-025 which states that entities shall conform to a registered Internet media type. In fact, there is no entry for it (the request been "pending" for many years) in the IANA media type register and there probably never will be. As stipulated in RFC 6838, only a recognized standards-related organization can request a media type in the standards tree. The vendor tree is not so restrictive--even a third party can register a type on behalf of someone else.
The following media type is suggested as an alternative (perhaps it can be registered by the OGC?):
application/vnd.a9.opensearchdescription+xml
Requirement-141 prescribes an exception report in the event that there is no record matching a given identifier; however, the status code 400 (Bad Request) isn't quite right as the request itself is valid (i.e. the request is accepted and processed). The universal convention for such an outcome is 404 (Not Found):
The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.
Table 19 states: "Only if no qualified name is used the NAMESPACE parameter can be omitted. In this case all elements are in the default namespace." Is the default namespace "http://www.opengis.net/cat/csw/3.0"? Does this then imply that typeNames=Record appearing without the namespace parameter is valid in a KVP query?
NOTE: The default namespace is the target namespace of the default output schema ("http://www.opengis.net/cat/csw/3.0").
In Table 19 the lexical representation of the namespace parameter is given as xmlns([prefix=]namespace-url).
However, the examples in cl. 7.3.4.1 do not agree with this scheme. Table 19 is taken to be authoritative (it seems to be based on the XPointer xmlns scheme).
The SearchStatus element is required in GetRecordsResponse. However, it contains only a timestamp attribute; there is a status attribute on SearchResults. Either put the status attribute on SearchStatus or remove SearchStatus altogether (push the timestamp attribute up to GetRecordsResponse or move it to SearchResults).
According to Requirement-031:
"The ows:BoundingBox element shall be used to express the spatial extent of a csw:Record record."
The @crs attribute must provide a CRS reference since no default is declared and it cannot be inferred from a broader context. The URI value presumably identifies a supported CRS.
Note: It is possible to substitute ows:WGS84BoundingBox for ows:BoundingBox (the applicable CRS in this case is http://www.opengis.net/def/crs/OGC/1.3/CRS84).
In OGC 10-032r8, ATC A.3 doesn't specify how envelopes are represented in the response. Tables 4 and 7 suggest that a GeoRSS element is expected, but the actual encoding (Simple or GML) is unspecified. Either of the following is acceptable:
-
georss:box(EPSG 4326) -
georss:where/{http://www.opengis.net/gml}Envelope(any CRS)
Table 6 declares that the "q" parameter is a list of terms "that are used to search all text fields in a catalogue record." The appropriate fields are not identified. In OGC 10-032r8 (OGC OpenSearch Geo and Time Extensions), Table 4 indicates that the searchTerms parameter shall apply to the following Dublin Core and Atom elements:
- dc:title | atom:title
- dc:description (dct:abstract) | atom:summary
- dc:subject | atom:category
The same mappings presumably apply to CSW text searches.