
Hi, As nobody objected I have made the changes to the SD spec. I attach the .pdf file. There is a changelog as required by the new procedure. Also see the comments in the errata file (also attached) For details of the changes see CVS and compare HEAD with the tag v-1 Steve

Shantenu, Andre and Thilo, I have still heard nothing so may I request that this be treated as a last call - giving people one week to react before it goes to the OGF editor. I attach a very slightly adjusted document from that circulated a month ago. Steve ---------- Forwarded message ---------- From: Steve Fisher <dr.s.m.fisher@gmail.com> Date: 2009/7/15 Subject: revised sd spec (gfd.144) To: SAGA RG <saga-rg@ogf.org> Hi, As nobody objected I have made the changes to the SD spec. I attach the .pdf file. There is a changelog as required by the new procedure. Also see the comments in the errata file (also attached) For details of the changes see CVS and compare HEAD with the tag v-1 Steve

Hi Steve, You removed table 1, because the Capability attribute was added to describe the service type the user searches for. I think the table should have been edited (not removed) to help to understand what GLUE Capability Keywords map to what SAGA packages(*). As it is, the user still does not know what keyword to use when searching for a URL suitable to construct a saga::job::service instance: executionmanagement.candidatesetgenerator executionmanagement.dynamicvmdeploy executionmanagement.executionandplanning executionmanagement.jobdescription executionmanagement.jobexecution executionmanagement.jobmanager executionmanagement.reservation Which one should I use for saga::job::service? Also, the GLUE enum is open, so arbitrary backend specific keywords can pop up, too. I still think that an implementation should translate something like 'saga.directory' into the respective GLUE keywords, as table 1 described before. BTW: the examples still contain |Type = 'org.ogf.saga.service.job'| and similar in various places, which seems to come out of the former table one. An oversight? Otherwise, it looks good to me to go (attrib names, ! Best, Andre. (*) I know I am complaining about the same item over and over again - sorry for that... Quoting [Steve Fisher] (Jul 15 2009):
Hi,
As nobody objected I have made the changes to the SD spec. I attach the .pdf file. There is a changelog as required by the new procedure. Also see the comments in the errata file (also attached)
For details of the changes see CVS and compare HEAD with the tag v-1
Steve
-- Nothing is ever easy.

saga-rg-bounces@ogf.org
[mailto:saga-rg-bounces@ogf.org] On Behalf Of Andre Merzky said: I think the table should have been edited (not removed) to help to understand what GLUE Capability Keywords map to what SAGA packages(*).
Actually from the GLUE side it's also rather hard to know what the Capabilities should be - I'm about to start trying to implement some glue 2 info providers, but I have no real idea what to publish for that. It would be good if someone could do a mapping to actual grid services currently in use ... Stephen -- Scanned by iCritical.
participants (3)
-
Andre Merzky
-
Burke, Stephen (STFC,RAL,PPD)
-
Steve Fisher