[jsdl-wg] Topics for the upcoming phone conference

[Michel Drescher]

*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>