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
Peter Baumann wrote:
The issue is that each specification (and combination of
core/extension specs) applies to both clients and servers
simultaneously. That is, some spec combination X which states "a
server may offer A or B or C" translates into "a client must be
prepared to handle A and B and C".
This is the only way that a client really can upfront (ie: before a
GetCoverage response is received) decide whether it can talk to this
server or not.
This is one of our curses: Every "should" in the specification, every
"may", every "if...else" multiplies the property space.)
more inline...
Aaron Braeckel wrote:
Renamed thread per Ben's suggestion.
If a 2D client talks to a 4D server, it has to be able to detect that
the WCS is beyond its capabilities but otherwise I'm not sure that much
additional complexity is imposed on clients. A process for describing
the dimensionality of the server is definitely important with an
N-dimensional WCS, but I think this is already largely covered by the
CRS description in the current WCS specification. I see it as another
flexible point in the specification. Just as the WCS does not mandate
any particular encoding format or specific CRS/data projection, it would
not mandate the dimensionality of the data. As in cases where an
unknown CRS is in use by a WCS server, a client makes a decision about
whether it is capable of handling that WCS implementation.
The reason I see N-dimensionality as preferable to a restricted
dimensionality is that the restriction:
-forces non-2D WCS implementors to fulfill a more complicated extension,
even when simple core functionality is all that is needed
-increases the number of necessary extensions, at least with how the
current extensions are described and laid out. Minimizing the number of
extensions seems beneficial to interoperability overall
-seems to cut the WCS functionality into groupings at a different angle
than the general coverage concept (i.e. less generalized coverage
capability)
Are there cases I am forgetting that might cause problems for 2D
implementors?
well, just think about 3-D image pyramids as the analogy to the
well-known map navigation accelerator. Also tiling gets a new quality.
-Peter
