NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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
galeon archives: