[jsdl-wg] GGF 13 notes and further discussion
Ali Anjomshoaa
ali at epcc.ed.ac.uk
Tue Mar 22 10:16:26 CST 2005
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 at epcc.ed.ac.uk
Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388
United Kingdom Fax: + 44 (0) 131 650 6555
-------------------------------------------------------------
More information about the jsdl-wg
mailing list