NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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 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.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"
(* 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").
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.-- provides a mechanism for establishing an additional "required supported format" by getting a profile for the additional encoding format approved by the OGC TC
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.)-- creates a WCS Annex E where approved WCS format profiles would be documented.
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.
I, too, wish WCS could be simpler to understand and implement. "If I were king..." :-)As you can tell, this is not as simple as the earlier draft. But then again, not much about WCS is simple.
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
galeon archives: