Michel Drescher wrote:
Session 1
- Fig. 1: suggestion to do a different document with scoping/explanation if this is controversial
My feeling is that we need "production versions" of all the figures anyway. Everything there at the moment just feels like embedded powerpoint slides... :^) That aside, we are probably going to have to do some kind of primer.
- multi-job [i.e. NAREGI] scenarios use container reference mechanism to pick up the needed pieces.
[This would require identifying name attributes that should be of type NCName so that the container can use QNames to refer to needed parts. Alternatively, XPath or XQuery are an option, although not really handy in this case, IMHO]
Being able to name things is good, and using xsd:NCName and a targetNamespace attribute on the outermost container element is a good way of doing it because it is like other XML specs.
Session 2
- Units - declare as QNames?
[I thought we agreed that units vanish and frequencies, bandwidth and storage are given, either as float or integer, with a fixed unit like Hz or Byte, respectively. However, can't find this in the notes stored at GridForge.]
My recollection is that every element will have its type fixed, but we didn't go through and do that because it wasn't controversial but was time-consuming.
- open content on data staging
[What does that mean?]
I think it's something to do with putting <xsd:any##other/> everywhere.
- ref/name: check tooling support
[Standard Java toolkits, SAX and W3C DOM, support this. However, AFAIK we didn't really clearly decide on using this.]
I thought we did decide to support this on the grounds that it makes life much easier down the road and it would be messy to add later on.
Session 3
- A tag to indicate what the client wants to be understood or not? Everything should be understood vs
[Hmm... vs what? What did we decide?]
All core elements MUST be understood already. :^) There's also no way to constrain extensibility elements I think.
- jsdl:Application xsd:any##other with cardinality 1 vs jsdl:ApplicationType with type xsd:any##other and list all applications that are defined separately
[No decisions on that so far, I think. It intertwines with Igor's proposal.]
My recollection matches this.
- need some tie-in to acs wrt [with respect to?] application definitions
My impression is that they're a long way off providing anything. At the very least, we should ignore them for now and get 1.0 out the door. We can patch this all up later on.
- [and these] limits should be under application executable
[so these are then basically part of the normative JSDL extensions, or are they supposed to be child elements of the jsdl:Application element which is the parent element of the future normative extensions?]
My recollection is that limits are to be sibling elements of Executable, Argument, etc. and that the limit types are to be done as individual elements instead of all as sub-elements of a Limits element (so we can get the typing right).
- [and the] limits are not used for resource selection; they are in the environment
Correct. Limits aren't resources (though the resources might act as bounds on acceptable limits on some systems).
Session 4
- Get rid of all String types?
Where possible. Hostnames still have to be strings I think...
- Ranges implicitly define operators, i.e. between 'a' and 'b'
Yes, or rather ranges subsume every operator that's useful in resource satisfaction description (unless you're doing something really nasty).
- Discuss on the list which resource constraints are global total constraints and which are per process constraints.
[Are there constraints that can be both? For example, One may constrain the job to use no more than 10 Gigabytes of physical memory, but each process must not consume more than 10 Megabytes of physical memory. Is this a valid use case?]
The other question is whether we want to support such things even if we have use-cases for them, or whether any case complex enough to require such things is outside the scope of what we wish to describe in JSDL 1.0 (without necessarily constraining future versions, of course). Donal.