[glue-wg] GLUE 2.0 Specification - draft 41 - Working GroupLastCall

[Burke, S (Stephen)]

>   That's everything for storage - there will be one more mail 
> about the type definitions, when I find the energy to write it!

Right, last lap on appendix B ... one general thing is that I think it
should say at the start exactly what "open enumeration" and "closed
enumeration" mean, and indeed what the mechanism is for adding to the
opne ones. Also it looks as though most, but not all, of the enumerated
values are in lower case - is there any particular reason for that? It
looks a bit odd in some cases, and doesn't match our current practice.
Also in some cases, e.g. ExpirationMode_t, the values are defined
elsewhere (e.g. the SRM spec) and have a definite case structure
already.

PolicyRule_t: I think this still needs more work. I don't understand how
the basic scheme can be just RECOMMENDed, surely if we define it it must
be mandatory? Also I still don't like the DENY in there, and if it is
there I think the semantics needs to be defined much more explicitly.
Indeed that's true in general, I don't think this is clear enough. It
also doesn't mention wildcard matching rules, which we need at least in
a simple form for EGEE. As more minor points we currently have VO: and
VOMS: rather than vo: and fqan:, is there a good reason for changing the
current practice? Also in the examples this is wrong in the EGEE
practice, for example VOMS:/atlas would *not* match /atlas/higgs
according to the EGEE-agreed matching rules. Should EGEE just ignore
this and define its own scheme?

Capability_t: I find this pretty hard to grasp, and if we are seriously
intending to make it mandatory (which I still think is a mistake) there
needs to be a lot of guidance to implementors on how to assign these in
practice.

ServiceType_t: as I already said I think this list needs to be extended
at least to cover the cases we know about in EGEE, OSG and Nordugrid.

EndpointTechnology_t: What does "legacy" mean? What would e.g. http
counts as? I would suggest having a value "custom" to mean a
service-specific protocol (e.g. the old NS interface to the WMS).
Describing (nearly) anything that isn't a web service as "legacy" seems
a bit extreme :)

DateTime_t: why restrict to GMT, is there any reason to disallow the
generic format? A Grid operating in e.g. Japan might find that annoying
...

Staging_t: why is it an open enumeration when it seems to cover all
possibilities?

ApplicationHandle_t: the description for softenv seems to be copied from
module.

OSName_t: for EGEE, after a long discussion we ended up with this for
the current schema:

http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_the_OS_name

If you plan to change that be prepared for some disagreements!

License_t: why is this a closed enumeration? The values seem quite
restrictive.

Stephen