<<saga_sd.dvi>> Andre, At last I have made the requested changes to the SD spec. Does anybody object to it going for public comment now? Steve
Looks great to me! One minor thingie: SIDL allows actually for default parameters, so instead of list_services (in string service_filter, in string data_filter, in string vo_filter, out array<service_description> services); list_services (in string service_filter, in string data_filter, out array<service_description> services); you could write list_services (in string service_filter, in string data_filter, in string vo_filter = "", out array<service_description> services); That would keep it consistent with the detailed spec, where you list only the long version (and rightly so). I think we agreed at OGF22 that we would not need another call on the mailing list, as we seem to have group agreement since quite some time. So, yes, I think its good to go to the Editor. Thanks!!! :-)) Best, Andre. Quoting [Fisher, SM (Steve)] (Mar 06 2008):
Subject: Emailing: saga_sd.dvi From: "Fisher, SM (Steve)" <S.M.Fisher@rl.ac.uk> To: Andre Merzky <andre@merzky.net> Cc: saga-rg@ggf.org
<<saga_sd.dvi>> Andre,
At last I have made the requested changes to the SD spec. Does anybody object to it going for public comment now?
Steve
-- "We've got too much time to waste to stand around here doing things." - Tigger
-----Original Message----- From: Andre Merzky [mailto:andre@merzky.net] Sent: 06 March 2008 16:47 To: Fisher, SM (Steve) Cc: Andre Merzky; saga-rg@ggf.org Subject: Re: Emailing: saga_sd.dvi
Looks great to me!
Thanks
One minor thingie: SIDL allows actually for default parameters, so instead of
list_services (in string service_filter, in string data_filter, in string vo_filter, out array<service_description> services);
list_services (in string service_filter, in string data_filter, out array<service_description> services);
you could write
list_services (in string service_filter, in string data_filter, in string vo_filter = "", out array<service_description> services);
That would keep it consistent with the detailed spec, where you list only the long version (and rightly so).
Where is this desribed please. I have been looking at https://computation.llnl.gov/casc/components/docs/users_guide/ Where looking at the JAVACC grammar in https://computation.llnl.gov/casc/components/docs/users_guide/node351.ht ml It says: /** * Parse a SIDL argument. Arguments begin with an optional copy modifier * followed by in, out, or inout followed by a type and a formal argument. * The argument is returned on the top of the argument stack. This routine * also checks that the copy modifier is used only for symbol objects. For * all other types, copy is redundant. */ Argument ::= [ <T_COPY> ] ( <T_IN> | <T_OUT> | <T_INOUT> ) (Type Identifier | Rarray) I want to make it quite clear in the spec that we are not saying that the vo_filter has a default value of "" - which is what this notation looks like for Python fans but that it can be omitted altogether! Steve
I think we agreed at OGF22 that we would not need another call on the mailing list, as we seem to have group agreement since quite some time. So, yes, I think its good to go to the Editor.
Thanks!!! :-))
Best, Andre.
Quoting [Fisher, SM (Steve)] (Mar 06 2008):
Subject: Emailing: saga_sd.dvi From: "Fisher, SM (Steve)" <S.M.Fisher@rl.ac.uk> To: Andre Merzky <andre@merzky.net> Cc: saga-rg@ggf.org
<<saga_sd.dvi>> Andre,
At last I have made the requested changes to the SD spec. Does anybody object to it going for public comment now?
Steve
-- "We've got too much time to waste to stand around here doing things." - Tigger
Quoting [Fisher, SM (Steve)] (Mar 06 2008):
That would keep it consistent with the detailed spec, where you list only the long version (and rightly so).
Where is this desribed please. I have been looking at https://computation.llnl.gov/casc/components/docs/users_guide/
Section 2.2.2 of the SAGA Core Spec: 2.2.2 Default Parameter Values This document, in several places, adds default values in the SIDL part of the API specification. It is up to the language bindings to exploit any native means for default parameter values. If this is not possible, the language binding CAN abstain from default parameter values. Also, if asynchronous method calls require additional parameters, which might affect the handling of default parameters in languages such as C and C++, the language binding CAN deviate from this document in that respect. So it would be up to the language binding really how that is interpreted. However, I see what you are saying with the default parameter versus the ommitted parameter. My wrong, I think we discussed this before. So I think its fine as is, but you may want to add the detailed description for the second version then, like: - list_services Purpose: return the set of services that pass the set of specified filters, for the current session Format: list_services (in string service_filter, in string data_filter, out array<service_description> services); Inputs: service_filter: filter on the basic service and site attributes and on related services data_filter: filter on key/value pairs associated with the service Outputs: - Throws: NotImplemented BadParameter AuthorizationFailed AuthenticationFailed NoSuccess Notes: - the semantics is identical to the overloaded list_services method from above, but it creates the VO filter from the VO attributes of the saga::contexts instances attached to the current session. Thanks, Andre.
Where looking at the JAVACC grammar in https://computation.llnl.gov/casc/components/docs/users_guide/node351.ht ml
It says:
/** * Parse a SIDL argument. Arguments begin with an optional copy modifier * followed by in, out, or inout followed by a type and a formal argument. * The argument is returned on the top of the argument stack. This routine * also checks that the copy modifier is used only for symbol objects. For * all other types, copy is redundant. */ Argument ::= [ <T_COPY> ] ( <T_IN> | <T_OUT> | <T_INOUT> ) (Type Identifier | Rarray)
I want to make it quite clear in the spec that we are not saying that the vo_filter has a default value of "" - which is what this notation looks like for Python fans but that it can be omitted altogether!
Steve
I think we agreed at OGF22 that we would not need another call on the mailing list, as we seem to have group agreement since quite some time. So, yes, I think its good to go to the Editor.
Thanks!!! :-))
Best, Andre.
Quoting [Fisher, SM (Steve)] (Mar 06 2008):
Subject: Emailing: saga_sd.dvi From: "Fisher, SM (Steve)" <S.M.Fisher@rl.ac.uk> To: Andre Merzky <andre@merzky.net> Cc: saga-rg@ggf.org
<<saga_sd.dvi>> Andre,
At last I have made the requested changes to the SD spec. Does anybody object to it going for public comment now?
Steve
-- "We've got too much time to waste to stand around here doing things." - Tigger
-- "We've got too much time to waste to stand around here doing things." - Tigger
Andre, Your suggested change would make the document longer without real benefit. I did notice I had a small error in the bibliography which I have corrected and I attach the .pdf file this time to make sure it goes around with the images. I think it should go to the OGF editor now to receive public comments. I have no doubt that I will then be asked to make varioss changes so I don't see any point in delaying further. Steve P.S. where do you get your SIDL definition from I thought I had the definitive one. > -----Original Message----- > From: Andre Merzky [mailto:andre@merzky.net] > Sent: 06 March 2008 18:52 > To: Fisher, SM (Steve) > Cc: Andre Merzky; saga-rg@ggf.org > Subject: Re: Emailing: saga_sd.dvi > > Quoting [Fisher, SM (Steve)] (Mar 06 2008): > > > > > That would keep it consistent with the detailed spec, where > > > you list only the long version (and rightly so). > > > > Where is this desribed please. I have been looking at > > https://computation.llnl.gov/casc/components/docs/users_guide/ > > Section 2.2.2 of the SAGA Core Spec: > > 2.2.2 Default Parameter Values > > This document, in several places, adds default values in > the SIDL part of the API specification. It is up to the > language bindings to exploit any native means for default > parameter values. If this is not possible, the language > binding CAN abstain from default parameter values. Also, > if asynchronous method calls require additional > parameters, which might affect the handling of default > parameters in languages such as C and C++, the language > binding CAN deviate from this document in that respect. > > So it would be up to the language binding really how that is > interpreted. > > However, I see what you are saying with the default > parameter versus the ommitted parameter. My wrong, I think > we discussed this before. So I think its fine as is, but > you may want to add the detailed description for the second > version then, like: > > - list_services > Purpose: return the set of services that pass the set of > specified filters, for the current session > Format: list_services (in string service_filter, > in string data_filter, > out array<service_description> > services); > Inputs: service_filter: filter on the basic service and > site attributes and on related > services > data_filter: filter on key/value pairs > associated with the service > Outputs: - > Throws: NotImplemented > BadParameter > AuthorizationFailed > AuthenticationFailed > NoSuccess > Notes: - the semantics is identical to the > overloaded list_services method from > above, but it creates the VO filter from > the VO attributes of the saga::contexts > instances attached to the current session. > > Thanks, Andre. > > > > Where looking at the JAVACC grammar in > > > https://computation.llnl.gov/casc/components/docs/users_guide/ > node351.ht > > ml > > > > It says: > > > > /** > > * Parse a SIDL argument. Arguments begin with an optional copy > > modifier > > * followed by in, out, or inout followed by a type and a formal > > argument. > > * The argument is returned on the top of the argument stack. This > > routine > > * also checks that the copy modifier is used only for > symbol objects. > > For > > * all other types, copy is redundant. > > */ > > Argument ::= [ <T_COPY> ] ( <T_IN> | <T_OUT> | <T_INOUT> ) > > (Type Identifier | Rarray) > > > > > > I want to make it quite clear in the spec that we are not > saying that > > the vo_filter has a default value of "" - which is what > this notation > > looks like for Python fans but that it can be omitted altogether! > > > > Steve > > > > > > > > I think we agreed at OGF22 that we would not need another > > > call on the mailing list, as we seem to have group agreement > > > since quite some time. So, yes, I think its good to go to > > > the Editor. > > > > > > Thanks!!! :-)) > > > > > > Best, Andre. > > > > > > > > > Quoting [Fisher, SM (Steve)] (Mar 06 2008): > > > > Subject: Emailing: saga_sd.dvi > > > > From: "Fisher, SM (Steve)" <S.M.Fisher@rl.ac.uk> > > > > To: Andre Merzky <andre@merzky.net> > > > > Cc: saga-rg@ggf.org > > > > > > > > <<saga_sd.dvi>> Andre, > > > > > > > > At last I have made the requested changes to the SD spec. > > > Does anybody > > > > object to it going for public comment now? > > > > > > > > Steve > > > > > > > > > > > > > > > > > > -- > > > "We've got too much time to waste to stand around here > doing things." > > > > - Tigger > > > > > > > -- > "We've got too much time to waste to stand around here doing things." > - Tigger >
participants (2)
-
Andre Merzky -
Fisher, SM (Steve)