Hi Ben,
I have some comments on what you wrote Sunday -- but first, here's how
the relevant section of the WCS 1.1 draft now reads, thanks to your
*prior* contributions:
= = = = = = = = = = = =
*9.3.2.2 SupportedFormats*
The /required/ *supportedFormats* element advertises the output
format(s) in which coverages may be requested from a coverage offering.
These formats are identified by a MIME type string. Any coverage format
that can adequately convey the domain and range of the requested
coverage is acceptable. However, for improved interoperability, clients
and servers should use formats defined in WCS encoding profiles adopted
by OGC. These profiles must contain the following information:
*MIME type(s) and brief description:* a concise overview of
the encoding format, including the MIME type string(s) used to refer to it.
*Pointers to documentation* for the encoding format. This
documentation must clarify how the encoding convention represents
locations, times, and physical quantities represented in the dataset.
* **Data model mapping* to the Coverage Abstract
Specification. This should include conventions for representing the
spatio-temporal domain, and for representing other dimensions in the
range. It should also describe limitations of the format for encoding
complex coverages, and limitations of the coverage model for
representing complex data structures allowed by the format.
*Examples:* A set of representative examples of the encoding
format.
*Pointers to implementing software* for the encoding
format.*
*Providers of this software may license it in source code or
executable form.
*Compliance Testing:* Pointers to mechanisms for testing
whether resulting WCS coverages conform to the encoding format.
= = = = = = = = = = = =
Now, on to your note about the 06-073 and 06-074 change proposals..:
I made an effort to incorporate as much as possible of the comments I
received on the earlier draft document that would have done away with
the WCS list of "required supported formats." The new approach is
not so simple. This one does the following:
-- "grandfathers" in the 5 original "required supported formats"
I think this "revert" would be a step backwards. Your change proposal
06-074 says "there is a significant concern that, if the list is done
away with completely or if there no guidelines for making additions to
the list, a key component of the WCS specification would be too
arbitrary and, in effect, would no longer be a standard." However,
simply having a list of 5 text strings won't help interoperability (and
will always leave someone out); what will help is the spec's
recommendation (*) to use WCS encoding profiles.
(* note the verb "should" in the 9.3.2.2 draft above)
-- leaves in the option of supporting any additional format as long as
one of the the "required supported formats" is required.
That was always the case, and remains so (because "should" is not "must").
-- provides a mechanism for establishing an additional "required
supported format" by getting a profile for the additional encoding
format approved by the OGC TC
Yes, I think this is the right answer to the problem. WCS 1.1 won't
disallow the use of HDF-EOS, GeoTIFF, etc. And it won't decrease
interoperability using these formats: clients and servers can exchange
MIME types (and hope for the best!) just as they did did in WCS 1.0.
However, with formats for which OGC has adopted a WCS encoding profile
(e.g., NetCDF-CF, hopefully soon), WCS 1.1 will support much more
predictable interoperability.
-- creates a WCS Annex E where approved WCS format profiles would be documented.
In fact, we've envisioned these profiles as separate documents from WCS
itself, rather than annexes. This will allow people to write (and OGC to
adopt) new encoding profiles without having to revise WCS every time. (I
realize that these profiles will each require a TC adoption process, so
it's not much of a shortcut -- more like a tidier partitioning of the
problem. For instance, it may prevent gratuitous tinkering with the core
WCS spec.)
We've slightly revised the content elements you prescribed for these
encoding profiles; however your 06-074 draft would fit the bill nicely
-- *if* it were to state the MIME type(s) used to denote the NetCDF-CF
format.
As you can tell, this is not as simple as the earlier draft. But then
again, not much about WCS is simple.
I, too, wish WCS could be simpler to understand and implement. "If I
were king..." :-)
For those of you who are OGC members, you can see 06-073 and 06-074
among the pending documents. I have not had adequate time for
proofreading these documents but I think I can still get corrections
in tomorrow before the dreaded 3-week rule kicks in for the next TC
meeting, so please let me know if you find any egregious errors. Of
course, the 3-week rule is there to allow for comments, so we can make
changes in that time frame as well.
Thanks, Ben, for your valuable contribution.
--
John D. Evans, Ph.D. <john.evans@xxxxxxxxxxxxx>
NASA Geoscience Interoperability Office / GST, Inc.
1-301-286-0803 / 1-240-542-1133
