On 24 August 2017 at 10:37, <stephen.burke@stfc.ac.uk> wrote:

Alessandro Paolini [mailto:alessandro.paolini@egi.eu] said:
> Stephen, do you mean that syntax could create problems for making queries, or other?

Yes, effectively you're creating a new mini-schema inside an attribute, so you'll have to build some kind of extra parser to manipulate it rather than just using whatever is native to the schema representation. For example, the numbers aren't numbers, just parts of strings, so you can't do numerical comparisons without extra parsing, or even verify that they are valid numbers. Also if an accelerator name is mistyped it's hard to detect, compared with an enumerated Type attribute where you can easily check whether it's a member. If you're trying to get new information into existing schema attributes that may be the only way to do it, but since we're modifying the schema here there's no reason not to do it properly.

> do you see any other option?

If there could be more accelerator types defined in the future my suggestion would be to have a new separate object class like AcceleratorInfo which would be related to the Share in the same kind of way as StorageShareCapacity.

I personally like this option. So each ComputingShare object would report the accelerator numbers in general, and through the new object class AcceleratorInfo we would have the information on the accelerators in particular for each ComputingShare.

Then the ComputingManager object could report the total numbers regardless the accelerators type, since the information on the accelerator types are already reported in the AcceleratorEnvironment object, related to the ExecutionEnvironment. Or do we need a new object for each accelerator type under ComputingManager as well for reporting the total numbers?