Phone Meeting

• Date: 30 Nov 2007
• Time: 8 AM Chicago, 2 PM London, 3 PM Rome (conversion to other timezones)
• Duration: 1,5h
  • traditional phone: +39 051 054 6636 (or any other on this list)
  • SIP-based phone: instructions
  • PIN: 1020
• Shared screen session information:
  • URL: http://glue-wg.glance.net
  • Key: 3011

Goal

• XML Schema
• LDAP - not discussed
• Relational - not discussed

Agenda

• Action Review:
  • artf6075

Participants:

• Sergio Andreozzi (INFN-CNAF)
• Marco Canaparo (INFN-CNAF)
• Balazs Konya (Lund University)

Apologies:

• Stephen Burke (RAL)
• Laurence Field (CERN)
• Felix Ehm (CERN)
• Shiraz Memon (FZJ)

Minutes

Balazs says that in ARC they are willing to start as soon as possible to use GLUE 2 - XML rendering - in WS-RF services using WS-ResourceProperties Sergio points at the current draft XML Schema + example which is aligned to latest GLUE spec (GLUE2XMLSchema) Balazs will forward this to ARC developers and will come back with feedback

All the discussion is aroud the XML rendering and rules:

ID/LocalID

• at the moment they are represented as attributes
• Balazs prefers to go for elements and use attributes for metadata-like information (e.g. Metadata.CreationTime and Metadata.Validity, see GLUE Spec, section 4.2)
• agreed

Open Enumeration

• Sergio describes open enumeration modeling issues in XML Schema together with comments got from Michel Drescher
• among the various solutions, we currently lean towards annotation/appinfo usage

XML Document structure

• Balazs asks about the structure of XML document; can individual entities be published alone? (e.g., an XML doc with a single service)
• Sergio says that in current modeling envisions
  • a root element called Grid
  • second level element called AdminDomain
  • third level element can be location/contact/service/...
  • if you want to publish a single service, you have to publish at least the Grid root and the AdminDomain
  • this can be evolved
• discussed several options now, a couple of them listed here
  • to be decided which one to follow; ask the group: artf6088

Flattening when possible

• Balazs: we should avoid deep document when possible
• Sergio: the rule seems to be: when entities do not have LocalID/ID and have 1-to-1 relationship with parent, it is possible to merge the elements to the parent
  • current matching entities are Downtime, SharePolicy and ShareState; applying this rule means:

from this
<Service>
    <ID>..</ID
   <Downtime>
         <DowntimeAnnounce>...</DowntimeAnnounce>
         <DowntimeStart>...</DowntimeStart>
          ...
   </Downtime>
</Service>
to:
<Service>
    <ID>..</ID
    <DowntimeAnnounce>...</DowntimeAnnounce>
    <DowntimeStart>...</DowntimeStart>
    ...
    </Downtime>
</Service>

• to be evaluated how this can be modeled in XML Schema by maintaining a complexType for Downtime
• not yet supported in current XML Schema rendering

Extensibility

• A number of extensibility options were discussed
• to decide which ones to support/recommend (artf6089)

New actions:

• artf6088, artf6089