• Date: 17 Mar 2008
• Time: 4 PM CET (conversion to other timezones)
• Duration: 1,5h
• Calling number: +41 22 76 77000 (ask to be connected to "GLUE Meeting")
• Shared screen session information:
  • URL: http://glue-wg.glance.net
  • Key: 1703

Agenda

Implementation

• XSD:
  • overview of structural changes proposed during OGF22 (e.g. aggregations)
  • Issues from Paul
  • wiki xml rendering cleanup, collection of examples
  • Issues from Balazs (nordugrid feedback)
  • Other issues
• SQL
  • Status
• LDAP
  • Status
• AOB

Resources

Issues from Paul

1. namespace

From a quick look, I spotted that the XSD defines a namespace: xmlns:glue="http://GLUE2" To my mind, this is broken: it should be a URI with FQDN + path. The path should include the year and/or a version number, allowing some version control.

Sergio: this was a placeholder, just sent email to Joel about OGF recommendation; OGF maintains also a repository for schemas: http://schemas.ogf.org/

2. Hierarchy

My concern was that, with the current binding, all valid documents are required to express the complete GLUE hierarchy. The current XSD expresses this by requiring documents have a "Grid" top-level element to be valid.

This requirement does not come from XML and XSD. Moreover, I believe that, by GLUE-2.0/XML introducing this requirement, an unnecessary burden will be placed on the info-providers. This will make implementing them harder, require explicit configuration and so make the process needlessly more fragile.

It would also prevents the information being published into more than one GLUE-based information system.

As a specific proposal, I suggest that other elements be allowed as top-level elements; for example, that a StorageService be a valid top-level element. The primary document from a StorageService info-provider should have a StorageService as its top-level element.

i.e., just added:

<element name="StorageService" type="glue:StorageService_t"/>

after the Grid one, near the beginning of the XSD.

3. Nested Domains

That said, the current XSD doesn't seem to support nested AdminDomain elements, which would be needed to describe distributed sites.

4. how to merge fragments of information conforming GLUE 2 http://www.ogf.org/pipermail/glue-wg/2007-December/000249.html

Participants

• Sergio Andreozzi (CNAF)
• Felix Ehm (CERN)
• Balazs Konya (Lund Uni)

Minutes

1. changes to XSD made during OGF

1.1 Associations: changed way to represent associations; now every element which has associations to other elements, will carry an <Associations> tag containing a number of elements referring the ID/LocalID of the associated entity

Open Issue 1: is there any problem if we use LocalID in associations? so far, it seems no;

sol.1 state that the scope of the association referring a LocalID is local to the main entity; (to be better clarified)

sol.2 use always Global ID; in case of LocalID, some prefix which make it global should be used (e.g. ComputingServiceID:ComputingShareLocalID)

Open Issue 2: it would be useful to use wildcards in associations; e.g.: in a ComputingService, there are 5 ExecutionEnvironments and 100 ApplicationEnvironment; I want to express that each ExecutionEnvironment can access ALL the ApplicationEnvironment withouth listing all ID's; something like:

<ExecutionEnvironment> <Assocations> <ApplicationEnvironmentLocalID>*</ApplicationEnvironmentLocalID> </Assocations> </ExecutionEnvironment>

1.2 introduced grouping elements for elements which are expected to be numerous (implementation aspect, does not affect conceptual model)

current grouping tags:

• <Services>
• <Activities>
• <ApplicationEnvironments>
• <ComputingActivities>

the criterion is to add groupings for elements which are expected to be in order of (10) or greather as siblings and of the same type what about ComputingShare?

Issues from Paul:

1. Namespace:

written mail to Joel for OGF recommendation, waiting for answer it could be something like: http://schemas.ogf.org/glue/2008/05/glue

2. hierarchy:

about usability:

• do we want queries to be able to work on both aggregated XML documents describing GLUE services and to individual service?

sol.1 full-hierarchy always:

/Grid/AdminDomain/Services/Service /Grid/AdminDomain/Services/ComputingService /Grid/AdminDomain/Services/StorageService

the mandatory attribute for AdminDomain is ID; if the services does not know about its AdminDomainID; it could publish UNKNOWN

sol.2 documents can contains:

a. Grid/AdminDomain/..... b. AdminDomain c. TypeService/ d. TypeActivity/ /../ComputingService

<Grid>
 <AdminDomain>
   <ComputingService>

<ComputingService>

in this case, it should made clear in the spec how the documents should be aggregated; the global hiearchy should be well-defined (see 4. from Paul comments) Need more discussion

3. Nested Domains

requirement: no increase of hierarchy

proposed rendering:

<Grid>
 <AdminDomain>
   <ID>CNAF-T1</ID>
   ....
   <Associations>
      <AdminDomainID type="contained">EGEE</ID>   
	  <AdminDomainID type="peer">CERN</ID>

<Grid>
 <AdminDomain>
   <ID>EGEE</ID>
   <Associations>
      <AdminDomainID type="container">CNAF-T1</ID>
	  <AdminDomainID>CERN-T0</ID>
....	  

Agreement

Issues from Balazs:

most of them were discussed; the missing issue is about how to query by type; i.e., how can we query elements which inherits from the same type

e.g. I want to query all services regardless if they are Service/ComputingService/StorageService

AOB: Top-level element. At the moment, it is called Grid; do we want to change it? e.g.: GLUE, Infrastructure, ...

Actions:

• Sergio: to clean XML Schema wiki page (remove obsolete content, add new one)
• Felix, Balazs: to add link to XML documents with examples in the wiki page plus a short description of the examples

Summary Open Issues

• ID vs. LocalID and scope in associations
• Namespace
• Hierarchy
• Querying by type hierarchy
• Top-level element name