Date: 17 July 2006

Participants:

Jay Unger, IBM
Ellen Stokes, IBM
Ravi Subramanian, Intel
Hiro Kishimoto, Fujitsu
Michel Drescher, Fujitsu
Andreas Savva, Fujitsu
Pete Ziu, Northrop Grumman
Stephen McGough, Imperial College
Andrew Grimshaw, UoV

** The future of JSDL (version 2.0?) **

- The group discusses what implications the new proposed information model
 structure may have on the future of JSDL.

- Andrew states that JSDL combines purely informational information on jobs and
 users with imperative information that is used to execute the job properly
 (e.g. user login name)

- Jay and Ravi both stated that the adoption of the "class-ad" like, symetrical,
  two part (Description / Requirements) model for both resources and jobs 
  actually is a pretty significant architectural change that affects a number
  of different WGs including, but probably not limited to: JSDL, RSS, BES, 
  Advanced Reservations, etc. Further Jay pointed out that many of the
  categories (Job Info, Application, Data Staging, Resources) elements 
  currently defined in JSDL will sort mostly into either the Description or 
  Requirements space but some of the elements contained in these categories may
  divide between Description and Requirements section in JSDL 2.0 (or whatever 
  we decide to call it).  

- There was a fairly long discussion of the fact that some of the categories of
  information in JSDL (like the Application stuff) is really more about 
  Description of "what to run" or "how to run it" (like program name, path, 
  environment variables etc.) and that stuff probably belongs to be in the 
  Description area.

- Ravi mentioned that he thought that it would be nice to be able to specify 
  information that is relatively invariant across a number of instances (job) 
  once as opposed to repeating it in every document.  There was general 
  discussion of how this could be accomplished with REF= attributes at various 
  points in the document, and there seemed to be general consensus that having 
  such a reference methodolgy would be good.

- Andrew pointed out that in some cases a more "abstract" document might 
  "resolve" into a more "concrete" form as the document passes through the 
  various stages of Execution Management and that the resolution of the 
  references might actaully depend on what "path" (e.g. what scheduling domain, 
  nodes, environments, etc.) are actually choosen to run the job in. Jay agreed
  with this point of view and said he thought that was a valauble mechanism in 
  its own right appart from simple "template like" references.

- There was some discussion about specific element names that might be choosen 
  at for both high level (container) parts of the document hierarchy and more 
  discrete values but there was not any real progress on making a concrete list
  with anything lile agreed to semantics. Ravi and Jay have agreed offline that
  neither the words "Capability" or "Feature" are likely sufficiently 
  semantically broad to be candidates for the top level dichotomy though they
  may have some value in the hierarchy lower down.

** Action Items **

1) Jay proposed that the JSDL folks should do a mapping from the current JSDL 
   elements / terminology into the new information model structure (Proposed 
   split into Description and Requirements)