[glue-wg] Answers to open questions

[Sergio Andreozzi]

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