NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.
Hi Andrew, 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 request.
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.
Ethan Woolf, A (Andrew) wrote:
Hi Jon, 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 coverages * adopts 07-112 proposal for 19123 irregular grids in GML (details to be added) 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? Regards, Andrew
-- 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/ ---------------------------------------------------------------------------
wcsplus archives: