• In the current draft, the physical location property is part of the Element concept; Can an Element have resources belonging to different physical locations?
• Element: the concept of element reminds an atomic concept, while our element is an aggregation of other concepts.

• in our model, a service does have a unique endpoint? If many endpoints are modeled, are they equivalent? How do you choose among them?

Collection of Questions and Open Issues

This section serves as a placeholder for open issues, it will not be part of the document. • static vs. dynamic attribute values • first, we should define what is static and dynamic • a possible improvement is to distinguish among configuration vs. monitoring • should static/configuration-related attribute be separated from dynamic attributes? • from time to time, people ask for that • pro: easier implementation • con: UML/Schema less readable and more complex • possible approach: • at the UML class diagram level, static vs. dynamic is not described by separation into different classes, but with annotations/tagged values • at the concrete data model level (relational, XMLSchema), static vs. dynamic can be considered in order to simplify the implementation • do we need a common authorization entity? • such kind of info is needed in several classes and we should have a common way to define them and to relate them to the various classes • how would this relate to the share • how to deal with extensibility? • in GLUE 1.3: tag-like approach: capability[*], (key,value)[*] • In which entities and in which way we should display owner information? • Contact support and ownership information, is it enough to have it at the site level or should we have also at the "element" level? • when reviewing the directory information in Computing Resource, consider the standardization activity on Grid job environment • service and endpoint; in our modeling, does a service have only one endpoint or can have multiple endpoints? • if many endpoints, then we need per-endpoint information • in Web Services world, a service instance has a single endpoint; • this needs to be discussed • how to deal with interactive jobs? where do we publish information about the service providing interaction with jobs? (a different service specialization together with the computing service?) • policy information is part of services or resources? • execution environments: how to deal with software packages that will be available only to certain VO's • application environment: • can we improve the modeling when the application environment is available homogeneously to the whole computing resource? • what about if they are available to only a certain VO/set of VOs? • computing share: • authorization policy vs. share • does this fully cover the concept of VOView of GLUE 1.3? • do we need priority in share? what is the use case for having them? • how to reflect policy on heterogeneous execution environment? • e.g., a share is associated to AMD and INTEL-based execution environment? do I want to be able to represent policy per type of execution environment? is it the trivial solution of splitting the share in two shares enough? • how to reflect authorization policies in the share? they should support not only VO's but also privilege attributes like one defined by VOMS • local vs. Grid job state information in shares (e.g., in nordugrid schema: nordugrid-queue-gridrunning nordugrid-queue-gridqueued nordugrid-queue-localqueued, nordugrid-queue-running) • status like production/draining/queuing/closed is per share or per service? • consider that waiting jobs can refer either to job waiting in the batch queue or in the front-end grid layer (e.g., during file staging); decide if the waitingJobs attribute refer to both or if we should add one more category (e.g. nordugrid-queue-prelrmsqueued ) • this consideration also applies to MaxWaiting • in GLUE we have assignedJobSlots and maxRunningJobs; we believe that modeling only the max running is enough