#	Issue	Author	Text	Discussion	Resolution
1	Use Cases in the Introduction	lfield	I would suggest removing the use cases in the introduction as they do not really add to the document and make it more confusing.	I think use cases in the intro are good, as to motivate the package, and give some context for its usage. - Andre We'd like a diagram showing how the API is invoked/used, ideally with a clear worked example, for the novices amongst us. Consequently We would support the use of actual use-cases in this specification and would resist any movement to get rid of them from the introduction, as suggested in another comment. - UWE Laurence discussed this with me before making the original comment. He had read it quickly and had seen the quotes as part of the text. The difficulty is that the wording of the use cases is confusing (for example it talks about components rather than services). I would like to remove the quoted text but to summarise the use case in a few words of my own. The reference to the use case document will of course be  retained. - Steve I don't think we need a picture - but I can add a few more words with the examples at the end of the document.  - Steve	Replace the quoted text with a summary Add a few more words with the examples at the end of the document.
2	vo_filter	sreynaud	Filtering by VO only is too restrictive compared to the security mechanisms supported by SAGA implementations. It can not be used with non-grid security contexts and it can not be used with non-VO attributes of grid security contexts (e.g. DN of proxy, VOMS role or group). I would suggest replacing 'VOFilter' with something like 'AuthzFilter'. I would also suggest using the same attribute names as for context attributes (e.g. 'UserVO', 'UserID') for consistency with the SAGA Core specification.	Yes - Andre No - I think the abstract concept of a VO is bigger than VOMS. For a non-grid deployment the "service provider" can publish the name of a group of people that might use the service. I could change the attribute name from VO to UserVO - except that this might imply that it is the VO of the user makign the query which is not the case - Steve
3	data_filter	sreynaud	The job management interfaces of SAGA Core specification can be used for uniform access to grid infrastructures because if defines both common methods and common attributes names for job description. We need something equivalent for service discovery; it would help a lot if the specification could define a set of common service data attribute names (e.g. a subset of GLUE property names) per service type (e.g. 'job_service.RunningJobs').	Yes - Andre I quite like the idea - perhaps it could go in an appendix as suggested attribute names. However I am not competent to choose this set of names and I fear it could cause long delays, so i would prefer not to do it. - Steve
4	service_filter	sreynaud	A paragraph explaining why different service type names are defined for 'file' and for 'directory' is needed. Same comment for 'logical-file' and 'logical-directory'.	Yes - Andre We could say that the File service is implemented by the file and directory classes and similarly for 'logical-file' and 'logical-directory'.  - Steve	On page 10 say that the File service is implemented by the file and directory classes and similarly for 'logical-file' and 'logical-directory'
5	discoverer	sreynaud	A SAGA implementation may support several discovery service end-points (with potentially different implementations) to enable simultaneous access to several grid infrastructures that do not interoperate. Hence I would suggest to add an argument of type URL to the constructor of class 'discoverer'. This argument could be optional.	Yes - Andre	Add an optional argument when creating a discoverer to guide the implementation in locating the underyling information system.
6	discoverer not available	UWE	What happens if a discovery service instance being queried is not available? Can a user contact another instance? Or which fault tolerant mechanism should be considered to access services which are not listed on a particular information system?	That is up to the SAGA implementation.  One implementation may just fail, another may fall back to another service, a third one may to collect information from a set of available services (probably preferred). - Andre I think this is also addressed by the issue above from "sreynaud"	Add an explanation to the document
7	Access Control	UWE	Access control mechanism is not discussed. How can user set access privileges on the discovery service contents? Different users have different privileges and there should be a mechanism where users can get the information based on their access right.	The discover is created in  a saga::session, thus has a set of saga::context's available.  Only with these credentials it can perform queries.  Also, these credentials identify the user to the backend, thus potentially allowing to perform server side authorization on that ID. - Andre	Add an explanation to the document
8	Stale services	UWE	Stale services can appear in user requests and are not discussed in the spec. Grid and distributed systems are dynamic. Services may come and go at any time. There should be a mechanism to identify stale services, or the services which are down due to any reason.	You can't avoid stale services: even if the API confirms a service is not stale, it might be on the next call, and vice versa.  The SD API can only provide endpoints, but notguarantee availability, nor completeness. - Andre	Add an explanation to the document
9	Time stamping	UWE	Time stamping of services is not mentioned. How a user may know when a particular service was registered or can query certain values for a particular time instance/interval?	Hmm, I wonder if there is a use case for that...  Otherwise, this can very well be part of the free form service_data. - Andre If the underlying info system is using GLUE II then everything has a creation time and a lifetime. The implementation may choose not to return "expired" services.	I would like to note that it is the responsibility of the implemenation to apply any algorithm it chooses to return valid services - this might include ignoring services that have not refreshed their registration recently.
10	Legacy services	UWE	What to do if the published services are not standard webservices as is the case with most Grid Services? I do not think this API will be able to access legacy Grid applications or can identify non standard services.	The data model is not tied to web services, nor is the API. I don't see any reason why that should not work for not-web services. - Andre	I propose to say nothing
11	SQL variations	UWE	SQL Implementations are inconsistent and, usually, incompatible between vendors. In particular date and time syntax, string concatenation, nulls, and comparison case sensitivity often vary from vendor to vendor. How can applications users may be forced to use a single SQL syntax for all the implementations of discovery service?	The document refers to SQL92 syntax, which is a standard. Any deviation from this standard, e.g. due to vendor specific backend SQL, need either to be treanslated by the SAGA implementation (preferred), or to be well motivated and documented.  Indeed, different SQL versions would break portability, and IMHO compliance with the document. - Andre Data are all strings except  that page 11 says: If values are specified as numeric values and not in single quotes the service data will be converted from string to numeric for comparison. So there is no problem with dates and times. Case sensitivity is normally in the hands of the user (or in this case the service discovery implementor) - at least it is for MySQL and HSQLDB. However there is a problem with comparison of strings. I suggest that we say that you cannot use > and < on strings. - Steve	Forbid comparison of Strings other than equality, ineqaulity and LIKE.
12		UWE	Not clear whether the attributes of the discovered service bring the middleware information too.	Don't understand the point - I will go back and ask them - Steve
13	Adaptor loading	UWE	Can we automatically load the adaptor, once the discovered service is selected?	That is up to the implementation.  Not all implementations may be adaptor based. - Andre	I propose to say nothing
14	Punctuation	UWE	Punctuation is poor. Authors should address the comma and the semi-colon. They aid readability.		I will get someone who is "good at punctuation" to give it a read through at the end.
15	Typos	UWE	Typos : 'Intendeded' on page 1 'or a broker' should be 'or by using a broker' on page 4 'as they as' should be 'as they are' on page 6 'perfomed' should be 'performed' on page 11		These will be corrected