Entities to be discussed: Service, Endpoint

Phone Meeting

• Date: 15 Nov 2007
• Time: 9 AM Chicago, 3 PM London, 4 PM Rome (conversion to other timezones)
• Duration: 1,5h
• Calling number: +41 22 76 77000 (ask to be connected to "Glue Schema Meeting")
• Shared screen session information:
  • URL: http://glue-wg.glance.net
  • Key: 1511

Agenda

• Documentation for Best Practice on Implementations
  • Tracker Item from OGSA-WG
• Discussion of implementations: XML Schema (Sergio), LDAP (Laurence) and relational (Felix)
• Start discussing Endpoint if time available
• AOB

Meeting Material

• Latest XML Schema and examples
• Example LDIF
• Latest GLUE 2.0 spec
• Example Relational Model

Participants:

• Felix and Laurence (CERN)
• Sergio and Marco (CNAF)
• Shiraz (FZJ)
• Balazs (Lund University)

• Apologies Stephen B (RAL)

Minutes

Action from OGSA-WG

• OGSA-WG asks GLUE-WG to create page with description of best practices/design guidelines for the GLUE 2 renderings.
  • AGREE

Things that the OGSA group wanted to see in the wiki:

• XML schema....something that is easily downloaded
• best practices so people have a good idea of how to use and how not to

• guidelines for extending the schema
• semantics for the schema...any additional descriptions/usage so users

XML Schema rendering

• ID/LocalID as XML Attribute and not as XML Element
  • Agree

• Relationship between AdminDomain and Location/Contact is rendered with parent-child relationship
  • pro: simpler to query; cons: redundancy of info

• request to change the schema def for location
  • Address to be changed in
    • Address: Street
    • Place: name of town/city
    • Country
    • PostCode

• many-to-many relationships
  • approach 1
    • add extra element with ID of associated instances
    • <computingservice>
      • <endpoint ID=A>
      • </endpoint>
      • <endpoint ID=B>
      • </endpoint>
      • <share ID=A>
      • </share>
      • <share ID=B>
      • </share>
      • <endpoint_share endpointID=A shareID=A>
      • <endpoint_share endpointID=A shareID=B>
    • </computingservice>
  • approach 2
    • <computingservice>
      • <endpoint ID=A>
        • <RefShare ID=A>
        • <RefShare ID=B>
      • </endpoint>
      • <endpoint ID=B>
      • </endpoint>
      • <share ID=A>
        • <RefEndpoint ID=A>
      • </share>
      • <share ID=B>
        • <RefEndpoint ID=A>
      • </share>
    • </computingservice>
  • Approach 1 is preferred

• Discussion on ExecutionEnvironemnt and ApplicationEnvironment relationship
  • approach 1, like previous approach 1
  • approach 2, include ApplicationEnvironment into ExecutionEnvironment
    • pro: simpler to query, con: redundancy
  • no decision, to be discussed when we revise the schema

• Timestamp: we decided for UNIX Timestamp
  • suggestion from Michel Dresher: go for dateTime XML Schema data type
  • UNIX Timestamp will overflow in 2038 when represented on 32 bit (year2038bug)
  • some discussion on situation in relational DBMS
  • comment from Balazs: check what people from Usage Records are doing; they have several timestamp-like attributes

Relational rendering

• description from Felix
  • UniqueID is GLUE 2 ID
  • Location contains location for adminDomain and Service
    • ParentType used to identify the parent category
  • multi-values in common table for all the tables
    • in current prod implementation of GLUE2, this table contains 100K entries
  • suggestion to add location attributes in adminDomain and Service table
    • pro: usability con: redundancy
  • Balazs: how do we deal with scalability for Job table?
    • Sergio: consider table partitioning todays supported by PostgreSQL, Oracle (Felix: and MySQL)