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

[Florido Paganelli]

Thanks for the comments Stephen, I agree on most of them. However I'd
like to avoid discussing every change by email as I find it dispersive.

Would you prefer that I provide a .docx that you can comment on? it
helps in meetings to tackle down decisions and track each person's
comment, and helps me optimizing the little time I have for GLUE2.

Cheers,
Florido

On 2014-05-03 14:26, stephen.burke at stfc.ac.uk wrote:
> 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
> 


-- 
==================================================
 Florido Paganelli
   ARC Middleware Developer - NorduGrid Collaboration
   System Administrator
 Lund University
 Department of Physics
 Division of Particle Physics
 BOX118
 221 00 Lund
 Office Location: Fysikum, Hus B, Rum B313
 Office Tel: 046-2220272
 Email: florido.paganelli at REMOVE_THIShep.lu.se
 Homepage: http://www.hep.lu.se/staff/paganelli
==================================================