Sergio Andreozzi [mailto:sergio.andreozzi@cnaf.infn.it] said:
- when I instantiate the endpoint, what associations must be instantiated?
I can see that can make sense in some cases, e.g. if there is a ShareCapacity there must be a Share to attach it to. However, for the main entities that isn't the case, e.g. you can have a Share without a Resource or a Resource without a Share, so the relation can't be mandatory.
All the definitions have a section labelled "Association End" - what does "End" mean there?
it is borrowed by the UML world.
Maybe it is, but I doubt that most readers will be UML experts ...can't it just be called "Association"?
In fact although the description says that everything inherits from Entity I suspect that excludes Extension?
[...]
if Class A inherits from class B, then class A inherits all the class B attributes *plus* all its associations;
I phrased that badly, what I meant was that Extension does *not* inherit from Entity even though the text says that everything does. Actually Paul suggested that maybe Extension should inherit from Entity and there could be some logic to that - if you did that then you could have Extensions to Extensions so it would be possible to build a more complex extension structure.
I agree with your proposal; I can make the following changes: - Rename Key to ID (unless we want ID, Key, Value)
Actually that is what I was suggesting, i.e. to have ID (or LocalID), Key and Value - we have a general rule that the IDs should not have any semantics so they shouldn't be keys. Secondly you would need that to allow the possibility of several Extension objects with the same Key.
AdminDomain: I think Owner needs to be defined better.
what about: Identification of the person or legal entity which pays for the services and resources
It still isn't entirely clear what "identification" means - this is somewhere that examples would help.
the UserManager is actually an Endpoint.ID and not the URL; therefore it identifies an endpoint class instance with all the info
Well, then it's surely wrong, it should be an association and not an attribute. Also the structure gets more complicated, you will need a Service to attach the Endpoint(s) to ... I'd be interested to see what this would look like in practice. It's also worth remembering that there may be several VOMS endpoints for a given VO, maybe at different sites, used for failover.
Service: it's not entirely obvious to me why Capability is mandatory.
let's say that you want to search for all job execution services regardless their interface/implementation;
I can see that you *may* want to search like that, but is this so vital that we say that everyone *must* publish this for *every* endpoint and service? For EGEE at least I would think that we'd want this to be optional.
Also I think the enumerated Type list in the appendix is inadequate,
it is an open enumeration, therefore if values do not match, not problem to publish something extra; it is probably out of scope to provide a complete list;
It can't be complete but I think we should at least cover the standard cases - what are people supposed to do when they start writing info providers? They will be stuck at the first step ...
And I don't understand why or how Type and Version are combined as a single Interface URI:
[...]
this emerged during the revision process with Balazs; one of the most wanted query pattern is: I want to search for an endpoint complying with an interface name an version, plus some extensions as well.
OK, but what's wrong with doing (&(Type=SRM)(Version=2.2.0)) or the equivalent in other technologies? The whole point of the schema implementations should be to make queries efficient; putting multiple items in one attribute just undermines that, effectively you have a mini-schema within the attribute. In the limit we could have a single attribute per object with a huge URI that concatenates everything!
the problem sits mainly in the extensions; by coupling the name and version into one attributes, we can maintain simple properties
That doesn't make much sense to me, an attribute which concatenates several things is complex, not simple. What if I *don't* care about the version, just the type? What if I want to do Version>x? In any case, you didn't address my point that the Type values *must* continue to be an enumerated list as they are now - this is really the core of the entire schema, you can't do anything without knowing what the endpoint types are.
I'm not strong on this; TrustedCA is somewhat independent from the policies you set (thought it is related);
It is an access policy, i.e. it specifies who is allowed to access the endpoint/service. It's true that it's somewhat different in format to, say, a VOMS FQAN - but we want the Policy object to be generic, so it should be able to cope with that.
And I still think the Downtime attributes should be in a separate object,
[...]
this was done also for simplifying the query and because the relationship is 1--1.
The relationship *isn't* 1-1, there may be several upcoming downtimes for the same endpoint, you just forced it to be 1-1 (first downtime only) to make it fit!
Share: the Endpoint and Resource relations are marked as mandatory, which doesn't seem right since the objects are supposed to be optional.
that means, if you instantiate a share, than you must instantiate an association to an existing resource and and existing endpoint;
I'm not sure what you mean by "existing". If you're saying that *if* the Endpoint and Share both exist then you should fill in the relations too then I guess that makes sense, but I think it should be clarified that that is the meaning. However, that doesn't seem to match what you have for other things, e.g. Service to Endpoint is marked as *, but the same argument would apply there, *if* Endpoint objects exist for a given Service then the relation from Service should be filled in, it isn't optional in that case.
in this particular case, anyway, this is a kind of "pattern"; share and reource are abstract (and so the relationships) which means not meant to be instantiated, but subclussed
But presumably the subclasses inherit the multiplicities for the associations?
about ID/LocalID probably we need more experience; apart a few cases, I don't know when to lean in one direction or in the other
I think there are two cases: you need a unique ID when you have associations that span across services, or where some external service like a catalogue may need to store the ID. For Manager, I'm not sure that either of those apply because you don't access the manager software directly. For Resource there is in fact a use case that just arose: Steve Traylen is looking at having a GlueService (basically a gridftp server) linked to a SubCluster to let people modify the RunTimeEnvironment tags. In Glue 2 terms ... hmm, I would expect that to be in the ExecutionEnvironment, i.e. Resource, but in fact I don't see it - what is supposed to be the Glue 2 equivalent of the RTE?
here you raise a new possible use case: do we want to allow to publish a service with no endpoint and no share, but a manager and a resource?
At least, I'm not sure we should forbid it at the schema level. (A read-only classic SE which only supports NFS access?)
given the assocations multiplicity, at the moment we can have:
1. Service 2. Service + Endpoint 3. Service + Endpoing + Manager + Resource
I think we should allow Manager without Endpoint (classic SE with NFS, CE with local submission only, ...) Stephen