*grmmmll* This mil is clearly outdated. The ML software took quite some time to chew on it... Sorry. Michel On 29 Mar 2005, at 11:43, Michel Drescher wrote:
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
<draft-ggf-jsdl-spec-0.9.5-00.doc>