Burke, S (Stephen) wrote:
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"?
That term is also being used already for something else. What about "ability"? (I did not check if it makes sense everywhere.)
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.
For managers: "is managed by". For capacities: "has".
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). [...]
What about the good old Implementation?!
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 [...]
Either is fine with me.