[jsdl-wg] GGF 13 notes and further discussion

[Donal K. Fellows]

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.