Thanks for putting this together. A few comments and questions:
1) I agree it would be easy to get bogged down in the details of further
spec-ing out asynch capabilities. To that end, I agree we should move
forward with the WPS approach as DEWS WCS implemented and you spell out
in your WCS 1.0+ document.
My only concern with taking the WPS approach is that it doesn't seem to
allow the server to provide estimates for process completion
time/duration. Unless I missed it the only estimate was a "percent
complete" integer value. I really see asynch capabilities as requiring
negotiation (or at least access to time estimates) before the actual
Oh, I see you have added a creationTime to the Status element. Sorry,
I'm loosing track of these details -- is that from the DEWS spec or a
new addition? I'm assuming that is an estimate for creation of the
output rather than the time of process creation/request. Is that right?
A similar addition would allow for ProcessAccepted processing duration
estimates or even pre-request estimates.
2) You mention that 1.1 allows nested coverage but it doesn't look like
you use that anywhere. Is that correct? I'm not suggesting we do as it
does seem of little use (sharing metadata). Just wanted to double check.
3) I find the 1.0 description of RangeSet and axisDescription
(especially what multiple occurrences means) a bit confusing and
unclear. In 1.1, RangeSet is replaced by Field and the multiple
occurrences of Axis are for multiple dimensional vector parameters. That
seems much clearer than 1.0. So, I'm wondering if we should modify
rangeSet to allow multiple RangeSet-s (or use the 1.1 Field) rather than
using multiple axisDescription-s.
4) I like your alternate option for GetCoverage KVP encoding. More 1.1
than 1.0 but seems to make more sense.
5) HTTP response codes.
At a minimum, I'd like to propose we agree to:
200 response codes for successful responses
400 response codes for exception report responses
Clients might want to think about (but probably not important for 1.0+)
3xx for redirects (301, 302, and 307, at least)
401 for authorization capabilities
6) Google Docs works for me.
7) OK, that's it for now. I'll have some CRS questions soon. In
particular, I'm in the middle of trying to understand GML CRS stuff, OGC
CRS URNs, and how the CF "grid mappings" and GRIB grids would map into that.
Woolf, A (Andrew) wrote:
My perspective: The effort initially was proposed as an 'implementation
interop' experiment between Unidata, CNR-IMAA, STFC, and the Met Office.
Of course if something useful comes out, then that will be fed back to
OGC membership and WCS RWG.
The motivation is very definitely to avoid lengthy 'specification
develpment' arguments and get on with actual implementations that do
what we need. Unidata and STFC hope to develop servers, and CNR-IMAA a
client, with Met Office playing a role in review against operational
requirements (I hope I'm not misrepresenting anyone's intentions).
The aim also is to stick as closely as possible to WCS 1.0 and avoid as
much as possible inventing new things. The key issues identified from
GALEON 1, and targets of this exercise are: asynch, heterogeneous
coverages, irregular grids.
To that end, I'm sending an initial draft outline of capabilities that:
* adopts a WPS approach for asynch, proven in the DEWS WCS (Jon I stole
some of your words here)
* minimally 're-interprets' 1.0 AxisDescription for heterogeneous
* adopts 07-112 proposal for 19123 irregular grids in GML (details to
Regarding the asynch, I think there's a danger in trying to make 1.0+
solve the full spectrum of use cases, that we might get too bogged down
in 'designing the spec' to actually get on with the implmentations that
are the focus of this exercise. Given DEWS success, and the existing
approach of WPS, it seems to me that's a good thing to focus on. I've
adopted the WPS ExecuteResponse as Jon indicated would work.
My suggestion is that we try and converge on an agreed spec as quickly
as possible - sticking with the 'minimal change' and 'implementation
focus' principles agreed, even to the detriment of functionality.
Ben suggested Google docs as a mechanism for collaborative work on the
spec doc - what do people think?
Ethan R. Davis Telephone: (303) 497-8155
Software Engineer Fax: (303) 497-8690
UCAR Unidata Program Center E-mail: edavis@xxxxxxxx
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/