[glue-wg] Updated Enumerations CSV files and new Proposal was: Re: Notes: GLUE WG teleconference, Tuesday, April 8, 2014

[stephen.burke at stfc.ac.uk]

Florido Paganelli [mailto:florido.paganelli at hep.lu.se] said:
> An updated version of the enumerations Procedures and Best Practices is
> here:
> 
>   http://redmine.ogf.org/dmsf_files/13224?download=

"2.1 Services:"

You should say that this relates to the ServiceType_t enumeration.

"2) Clients SHOULD consider these strings case insensitive."

Given that the schema defines them as case sensitive I don't think it's a good idea for clients to do anything different, it's likely to lead to confusion. The reason for preferring lower-case names is precisely to make that easier, but if the enumerations are mixed-case (which we have in some cases for backward-compatibility) then the clients need to preserve that, otherwise queries may fail.

"<organization_name>
is the reversed domain name of the organization."

That probably needs a bit more explanation, something like "a domain associated with the project or organisation which provides or maintains the service". 

"Presence: MANDATORY for new names"

I think that should be RECOMMENDED - there may be exceptions, e.g. where existing names are imported into GLUE. Exceptions should be justified.

"Presence: NOT MANDATORY"

Should be OPTIONAL. Also the syntax should have square brackets around that part. We may also want to restrict the allowed character set.

"Exisiting names not following the above rules can be kept, but should be Deprecated (see
Section 4.1)"

I don't agree - deprecation implies that a new name should be defined, and in general I don't think that would be worthwhile if the existing name is widely used.

"2.2 Interfaces:
GFD.147 Appendix B.18 does not define any clear format."

This relates to InterfaceName_t. I think the rules can be the same as for ServiceType_t.

"2.3 Capabilities:
See GFD.147, appendix B.5, on Capability_t."

If people are going to define new Capabilities there probably needs to be more guidance on how to do it.

There are many more enumerations than just those three - I'm not sure if they're all obvious from the schema doc. At least the OS naming and CPU architecture have caused problems in the past - see

https://wiki.egi.eu/wiki/HOWTO05_How_to_publish_the_OS_name

https://wiki.egi.eu/wiki/HOWTO06_How_to_publish_the_system_architecture

"For EMIR, developed during EMI project that now is over"

Even if projects end I think names should normally be preserved. (Also in that particular case the EMI domain still exists at the moment.) It seems fairly unlikely that a new, unrelated (but still Grid-related) project would be created which re-uses a domain name.

"Description of the enumeration. This description is a textual, human readable
summary of what the object described by the open enumeration does."

I think there are in fact two things required - a concise description that will be stored as part of the definition of the enumerated types, and a (usually) longer description that will explain to the WG what the new type is for.

"Request for addition/deletion/modification"

I'd suggest "deprecation/obsoletion" rather than "deletion" - once names have been defined I think the information should be preserved. I would also suggest a rule that obsolete names can't be re-used for something different, although they could potentially be re-activated for the same use.

Stephen

-- 
Scanned by iCritical.