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