Dear Steve and Donal, in the today GLUE telecon, we discussed a number of open questions sent to the list in the last period that were unanswered. Mainly they were from you. You can find the answers below. For other people who kindly provided comments in the past, we please ask them to check if the questions are still valid and send them again to the list. For the time being, please consider only the Main Entities. We are completing the discussion on them and we'll soon start to discuss the Computing Entities. Cheers, Sergio ------------- Q & A. From Steve: * Q.It was mentioned in Seattle that AdminDomain.distributed was hard to define and of no value and so should be dropped * A. we changed the definition to make explicit that the site administrator is in charge of deciding if an AdminDomain is distributed or not; we do not want to provide a way to define it; nonetheless, we feel useful to have this information * Q.It was also mentioned in Seattle that UserDomain.level was redundant and so should be removed * A. not yet discussed * Q. I don't see the value of AdminDomain.Owner * A. In production systems like NorduGrid and OSG people want to know who is paying for the resources; they are typically different from the administrators; * Q. I don't think we need Domain.OtherInfo we have the description and the web page * A. for several entities, we envision the need of adding extra info; at the moment we offer two ways: - OtherInfo attribute, multi-value, single-dimension -- easy to use and query - Auxiliries Entity->Extension, support many instances, bi-dimensional (key,value) -- separate name from value, a bit more complex to query * Q. IDs (as URIs) should be everywhere - but should never have meaning attached to them * A. each ID is a URI; LocalID are defined as "An opaque local identifier" and are strings * Q. 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. * A. added * Q. The Quality level, if we *really* want it belongs to the endpoint rather than the service * A. at the moment we have temporary added to both Service and Endpoint; when we'll have more experience, we'll make the final decision * Q. The endpoint looks rather big! * A. we separated the Downtime attributes, we have to evaluate the separation of State attributes * Q. All references to xxxVendor should be changed to avoid the word vendor as many software providers do not sell their products. * A. fixed Donald K. Fellows * Q. domain.otherinfo Looks like some random extensibility. It's not clear how much of that should be done by subclassing instead. And CSV? * A. for several entities, we envision the need of adding extra info; at the moment we offer two ways: - OtherInfo attribute, multi-value, single-dimension -- easy to use and query - Auxiliries Entity->Extension, support many instances, bi-dimensional (key,value) -- separate name from value, a bit more complex to query (CSV is just an example of possible synta) * Q.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. *** A. we agree; to be done * Q. 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). * A. not yet discussed, we'll consider it * Q. Are all Endpoints web-services endpoints? * A. no * Q. If not, consider defining a subclass WebServiceEndpoint and moving some of the current Endpoint attributes into it (e.g. WSDL URL, IssuerCA, TrustRootCA). * A. from the conceptual viewpoint this make sense; from GLUE viewpoint we want to avoid to create extra entities if not really needed since this will complicate the usability * Q. 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...) * A. we also have to verify it; it is still an open question * Q. 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!) * A. they have to be defined yet (see tracker item artf6076); we agree that this is a meaningful approach, nevertheless this will reduce usability for users; when searching for a certain category of endpoing, they have to write a longer string, harder to remember; * Q. 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! :-) * A. we are well-connected with Ellen; we also have plan to discuss GLUE2 with DMTF for inclusion into CIM Core; we are waiting for a stable proposal -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi