glue-wg-bounces@ogf.org

[mailto:glue-wg-bounces@ogf.org] On Behalf Of Balazs Konya said: Thursday we start with the following three entities, their related attributes and relationships: - admindomain - location - contact

I'm not sure if I'll be able to join, but I have a few comments: LocationAddress: is the format supposed to be defined so it can be parsed? I believe the GridPP Real Time Monitor application relies on the format as currently published in EGEE. Contact: I don't think the contact URI itself should be the key/uniqueid. As a general policy IDs should not have semantics, and in this case it's quite possible that e.g. several different types of contact could have the same email address. ContactOtherInfo: multiplicity should be * Domain: I somewhat wonder whether there should be a Type attribute, e.g. in LCG sites can be Tier-n, and maybe VOs have different types (local vs global?). However, maybe this is too Grid-specific to be in a special attribute rather than OtherInfo. DomainWWW: should this have multiplicity *? In some cases there may be more than one web page you could point to. Or maybe secondary web pages could just be in OtherInfo. AdminDomainOwner: the description needs to be expanded as to what is expected to go there. Looking a bit further forward, it looks like the "element" debate has been resolved by renaming Element to Service and Service to Endpoint. Given that people are used to the existing names I wonder if this change in nomenclature is useful. (And does service discovery now have to be called endpoint discovery?!) Stephen

Fisher, SM (Steve) wrote:

- It was mentioned in Seattle that AdminDomain.distributed was hard to define and of no value and so should be dropped

- It was also mentioned in Seattle that UserDomain.level was redundant and so should be removed

These two are both really very strange anyway. (And the level assumes that everything is always a strict tree. That's not true. DAG is more accurate.)

- I don't see the value of AdminDomain.Owner.

There should be the owner information in there somewhere, and it's valuable in scenarios involving co-location facilities. Maybe you don't do that, but we do. (It probably ought to be an association though.)

- I don't think we need Domain.OtherInfo we have the description and the web page

Looks like some random extensibility. It's not clear how much of that should be done by subclassing instead. And CSV? Oh dear...

- IDs (as URIs) should be everywhere - but should never have meaning attached to them.

I certainly agree about not attaching meanings to IDs. And when they're abused to mean "contact address", say that instead. OK, now for *my* contributions from a quick glance... 1) It might be nice if each class listed the inherited properties it has (even if it doesn't define what they mean). It'd make the schema easier to read. 2) There probably ought to be a standard space in the Policy class for describing the language/syntax/etc. used to describe the policy (as opposed to the purpose of the policy, which is identified by the particular subclass). 3) Are all Endpoints web-services endpoints? If not, consider defining a subclass WebServiceEndpoint and moving some of the current Endpoint attributes into it (e.g. WSDL URL, IssuerCA, TrustRootCA). I'd limit the number of WSDL URLs per WSEndpoint to 1 though; doesn't make much sense to state more than that. (I should check whether it's easy to refer to a particular service within a WSDL document, since I know you can publish many in the same doc...) 4) Categorizing by URI: Just define that a Compute Endpoint must have the Category URN set to, say, urn:OGF:Glue2:EndpointCategory:Compute (or you could substitute a URI or URL; it's an arbitrary string in the format of a URI, just like an XML namespace name is. I've not thought hard about the actual URN I gave as an example BTW, so I won't feel offended if you change it!) 5) The other thing to check for consistency with is CIM. (Alas, that's a hard task as CIM is colossal.) Try to sweet-talk Ellen Stokes into helping! :-) Donal.