Ethan-
sorry for the delay. The idea actually is that, as part of the
GetCapabilities response, a server provides a list of all extensions it
knows. (The WCS group would take care that every extension adopted gets
some unique identifier.) As extensions in the end usually boil down to
software components this is a matter of the service instance in general.
CRSs etc are on a finer-grain level, hence tied to individual coverages
indeed, as you correctly remark, and advertised per coverage (see
DescribeCoverage response). Note that we do not foresee extensions for
individual CRSs. Rather, the set of CRSs that make sense in presence of
a particular extension are defined by the domain axes (dimensions) - if
a server supports only 1-D time series then probably WGS84 will not be used.
In summary, extensions currently are foreseen to be communicated
"globally" for a server, ie: in the GetCapabilities response.
Hope that helps...
-Peter
Ethan Davis wrote:
Hi Peter, all,
Is there some part of the core + extensions framework that simplifies
the need for client/server negotiation in some way? The conversation so
far seems to imply that if a server supports some set of extensions then
any client that wants to access that server had better be able to handle
all those extensions.
That seems backwards to me. Isn't it the client that may require certain
extensions? If a server doesn't support the extensions the client
requires then the client should not continue accessing that server. For
example, if a client requires GeoTIFF or CF-netCDF, it can't
successfully access a coverage from a server that only supports HDF.
On the other hand, if the server supports the required extensions, it
may not matter if it also supports other extensions. Continuing the
above example, if the same server supports both CF-netCDF and HDF, the
client will be able to access a coverage if that coverage is offered in
CF-netCDF. The fact that the server also supports HDF doesn't affect the
client.
There is also the scope over which an extensions applies to worry about.
For instance, KVP and SOAP support would be server-wide. Whereas the
dimensionality of the CRS and encoding format often would be scoped to
particular coverages.
Does the core+extension framework provide an overarching way that
supported extensions are communicated to clients or does the location of
that information depend on the type of extension? For instance, KVP and
SOAP I seem to recall are indicated in the GetCapabilities document and
so would imply their server-wide scope. The CRS of a coverage and
available encoding formats are given for each coverage in the
DescribeCoverage document.
Ethan
