[jsdl-wg] REPOST: Topics for the upcoming phone conference

[Michel Drescher]

REPOST:
Identical to the first attempt except the spec doc. The first mail 
seemed not to pass the ML software. Please obtain the JSDL 
specification document from Gridforge.

---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP 
----------

Dear JSDL wranglers,

this is a list of topics I would like to be decided on at the today's 
phone conference.

(1) JobDefinition/@JSDLVersion attribute
The version of the JSDP spec is uniquely defined elsewhere, and encoded 
in the namespace. I do not see any use of this attribute.

(2) JobDefinition/JobIdentification/User/UserCredential
The spec contains a comment that this element "... can be handdled 
through the standard extension mechanism."
Let's decide on the phone conference to keep it or to drop it (and 
release it to the extension mechanism).

(3) range values
Karl and Stephen made a valuable proposal for a clear and efficient 
definition of range values:
      <lowerBound>xsd:integer</lowerBound> ?
      <upperBound>xsd:integer</upperBound> ?
      <exact>xsd:integer</exact> *
      <range>
         <lowerBound>xsd:integer</lowerBound>
         <upperBound>xsd:integer</upperBound>
      </range> *
I propose to replace our current definition of a range value with this 
complex structure.

(4) xsd:integer or xsd:double
Partly touching topic 3, there's a discussion on wether to use integers 
or fraction numbers. I propose to use xsd:double together with an 
optional attribute "epsilon=xsd:double" for precision restrictions, 
changing the range type to
      <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound> ?
      <upperBound epsilon="xsd:double"? >xsd:double</upperBound> ?
      <exact epsilon="xsd:double"? >xsd:double</exact> *
      <range>
         <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound>
         <upperBound epsilon="xsd:double"? >xsd:double</upperBound>
      </range> *

(5) (Non-)Critical extensions
There's a discussion at the moment to tag particular elements of JSDL 
to be (non-)critical in terms of understandability and support, similar 
to the SOAP attribute "mustUnderstand=xsd:boolean".
I propose to postpone this mechanism to after the first official JSDL 
release.

(6) naming elements
To promote reusage, elements of JSDL documents should be identifiable. 
An appropriate technique is using QNames. This requires the elements 
that we want to be reused to get a naming attribute of type xsd:NCName.
I propose to use this technique to promote reusage. If we agree to use 
this, a follow-up action point will be assiged to identify the elements 
that need this new naming attribute and to propose a naming syntax.

(7) Resource constraints global total and/or per process
During GGF13, the issue came up that a resource can be defined to be 
total global or as per process. A use case may be to constrain a job to 
10 Gigabytes of physical memory and at the same time to constrain the 
job's processes to consume no more than 10 Megabytes of physical 
memory.
I propose to reflect this in JSDL expressis verbis rather to punt it 
out to an extension.
If we agree on incorporating this, a follow-up action point will be the 
investigation and proposal of solution alternatives.

(8) Comments and flames on the current specification document
Although this is very short term, I attached the current latest version 
of the spec document - unofficial as I am not the official editor! - in 
which I tried to reflect all the changes we agreed on at GGF13. It was 
quite much, so expect to face errors in what I created.

Cheers,
Michel