Michel, thanks for this. I think you should carry on with the spec and address all those issues that are clear to you. Any that are not and are not addressed on the list, we should address at next week's telecon. You have the pen. Some comments below. Steve, Donal, anyone else any comments? Cheers, Ali On Tue, 22 Mar 2005, Michel Drescher wrote:
Session 1
- Fig. 1: suggestion to do a different document with scoping/explanation if this is controversial
Ali: Are we still planning to do a Primer based on v1.0 when that is released? Perhaps any extended clarification of scope should go in there.
- 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]
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.]
- open content on data staging
[What does that mean?]
Ali: One for Andreas or Steve...?
- 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.]
Ali: I think the decision was that if this could be done relatively painlessly, then we should do it.
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?]
Ali: "vs" nothing! "Everything should be understood" by a JSDL consumer.
- 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.]
Ali: IIRC, we decided to reference application type and have it defined externally.
- need some tie-in to acs wrt [with respect to?] application definitions
Ali: This is a new proposal. ACS is still being worked on and we should perhaps provide a mechanism to leverage their interface. Alternatively, perhaps their interface could look like our application type definition. One to discuss with them perhaps. Certainly outside v1.0 scope I think.
- [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?]
- [and the] limits are not used for resource selection; they are in the environment
Session 4
- Get rid of all String types?
Ali: So that parsers and engines match against QNames instead, right?
- Ranges implicitly define operators, i.e. between 'a' and 'b'
- 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?]
Ali: Right. So do we need an XML attribute to say if a constraint element applies at a global or per process level?
Cheers, Michel
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------