That's it for computing, storage to follow ...
OK ... on the diagram I again have doubts about the multiplicities: Share to Resource says 1..* at both ends but I think they should both be *. Conversely, Service to AccessProtocol says * but I'm inclined to think it should be 1..*, an SE with no way to access the data wouldn't be very useful ... As a general comment, the text uses the word "capacity" (or "capacities") in many places to mean something like "the ability to store data". I think this is a bad choice of word, partly because of possible confusion with the Capacity objects and partly because I don't think it's really the right word anyway. Also in some places the text uses "storage extent" to mean what seems to be something similar, and again I don't think "extent" is a very good word. However, I'm not entirely sure what to recommend as an alternative - perhaps "capability"? Service: four of the association descriptions use the word "offers", which I suspect isn't really the right word for most of them - for protocols it's OK, and maybe for Shares, but it doesn't really offer managers (they aren't externally visible) and it definitely doesn't offer Capacities, it just has them. SSCapacity: Here the word "capacity" appears in the description, so it seems that a Capacity object tells you the capacity of a capacity ... not very good! I think the *Size attributes need a more complete description, as this always seems to confuse people. Indeed there is no general explanatory text for this object and I think there should be some, e.g. to say that this is a whole-SE summary of the more detailed Share-level information. AP: The association to the SS2CS object (as shown in the diagram) is missing from the table. Again there is no explanatory text. Endpoint: are we expecting access protocol endpoints (e.g. for a classic SE) to be published as Endpoints or StorageEndpoints? There is no text to indicate what the endpoint is expected to be. Share: the Path is marked as mandatory - maybe that's OK and you should publish "/" if there is no specific path, but if so I think it should say so explicitly. Indeed it needs to be clearer exactly what the semantics are here - this is a SURL prefix to be used when files are written, and cannot in general be reverse-engineered, i.e. given a SURL you can't reliably deduce which Share it's in. Tag: I think we need a better description here, something which would correspond to the space token description for an SRM while being generic enough to be applicable to other technologies. In the associations, Endpoint and Resource are marked as mandatory when the objects are optional (and MappingPolicy is missing because it's missing from the main entities too). I think the text description for Share is not very clear. ShareCapacity: the description says "size and state" but in fact it's only the size. Again I think the attributes need a clearer description. The text below the table could also be clearer, at least my mental parser is currently throwing an error :) Manager: Type seems a slightly strange name for the attribute, things like "enstore" and "castor" aren't really types. Actually this applies to ComuptingManager too although I didn't pick it up there, are "lsf" and "pbs" types? Also since both CM and SM have a Type attribute should it anyway be defined in the parent Manager entity? (ditto Version). For the StorageResource association it says 1..* for the multiplicity but the text says "zero or more" - I think the text is right. There is no explanatory text below the table, I think there should be some. StorageResource: as you might guess I'm still inclined to prefer DataStore! Since we have ExecutionEnvironment and not ComputingResource this is evidently not a hard naming rule ... the description says "one or more endpoints/shares", it should be "zero or more". The Latency description is wrong, in this case it's the actual latency and not the maximum (tape is Nearline here even if it's part of a D1T1 Share). The Manager and Share associations say that they are mandatory, but I think the reality is a bit more complicated - you must have at least one of them otherwise the object will be completely detached, but logically either one of them could be missing - although possibly that would make a mess of the renderings. There is no explanatory text, this definitely needs some given all the trouble it causes ... SS2CS: The AccessProtocol relation is marked as multiplicity 1, but I think it should be *. One one side you could have a "close SE" relation involving several protocols (e.g. rfio and file). On the other side you may want to have the network info regardless of protocol (e.g. for gridftp). Again there is no general explanatory text for this object. That's everything for storage - there will be one more mail about the type definitions, when I find the energy to write it! Stephen