** Participants **
Chris Smith, Platform
David Snelling, Fujitsu
Michel Drescher, Fujitsu
Andreas Savva, Fujitsu
Pete Ziu, Northrop Grumman
Glenn Wasson, UvA
Marvin Theimer, Microsoft
Hiro Kishimoto, Fujitsu
Nick Werstiuk, Platform
Ian Foster, ANL
Ellen Stokes, IBM
Jay Unger, IBM
Andrew Grimshaw, UvA
Ravi Subramaniam, Intel
Steven McGough, Imperial College
Fred Maciel, Hitachi (via phone)
Darren Pulsipher, EMC (via phone)
Mark Morgan, UvA (via phone)

- Jay and Ellen gave joint presentation.

- The group discusses the implications of interoperability and metrics and 
  semantic descriptions:
  * There is no consensus on the rendering to use
  * Value of symmetry between advertisement and request
  * Core set of concepts
    - Semantics
    - Description of the semantics
    - Representation of the concepts is still undecided
  * Matching is the process of aligning the grid’s capabilities with the 
    requested requirements.
  * Choosing the correct node(s) is a matter of applying a quantification 
    algorithm that models best the actual scope, i.e. “best” in terms of
    - resource exploitation
    - performance for the job
  * Not only the resources can advertise capabilities and the job advertises 
    requirements, but it is also the other way round:
    - Resources have requirements on the jobs that they can accept (i.e. only
      EGEE or Naregi) and jobs have capabilities (i.e. it is an EGEE or 
      NAREGI job)
      ==> symmetry of advertised capabilities and requirements of both 
      	  resource and job

PROPOSAL: Jay and Ellen propose to use a derived version of XQuery to describe
	  resources
 
  * Full XQuery is too powerful → restrict!
  * Users are neither expected nor wanted to write their own XQuery
  * Good tooling support is available 

  SUB-PROPOSAL: Provide a common (OGSA) prologue that defines common OGSA 
  		functions, which users can include in their XQuery documents.
  * XQuery is capable to unify the access to XML storage or DB storage
  * XQueryX is an XML rendering of XQuery

PROPOSAL: XML Documents as the capability specification

  * Declarative format
  * Name-value pairs
  * 2-level limited hierarchy (Capability – Property)
  * The group realised the problems of typing in the different renderings
  * The group raises performance concerns about the XQuery proposal. 

  * The EMS document does not require to invoke the CSG process for every job
    submission.
  * The EMS document introduces a Job manager that literally statically assigns
    jobs to containers, so that time costly operations do not apply to tight
    performance requirements (i.e. 50’000 jobs scheduled within 100 
    milliseconds)

  * Type obedience
    - Issues are raised that type obedience to XSD schema may be too limiting
    - No typing restricts to string based operations which raises difficulties 
      with i.e. non-ASCII languages (example: “when sorting people’s names, 
      where are the Scottish ‘Mac’ names are sorted in”)
    - Relational languages and expressions require typing

PROPOSAL: use either “slide 8” or “slide 9” as our structural rendering, 
	  but add typing to whatever slide is selected

Preliminary decision: 
Typing is to be included into the proposal put forth earlier and come back with 
a proposal for typing with rendering on slide 8 and to examine what can be 
learned from CIM-XML on typing.