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?!)

"ID: The ID should be a localID. Since several Domains could share the same location, it makes sence to distinguish those by a localID." That isn't exactly how I would put it. The point is that even if several Domains had the same physical location you would want to publish separate Location objects, hence the Location is within the scope of the Domain and only needs a LocalID.

Steve Fischer

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

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

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

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

- I would like to see a many to many (directed) relationship between services to represent the fact that any service may have a set of related services. The precise meaning of that relationship is to be defined by the publisher of that information. Note that it is essential that it is considered to be directional.

- The Quality level, if we *really* want it belongs to the endpoint rather than the service

- The endpoint looks rather big! All references to xxxVendor should be changed to avoid the word vendor as many software providers do not sell their products.

Donald K. Fellows

> 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.

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.

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).

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...)

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!)

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! :-)