On Mar 22, Michel Drescher loaded a tape reading:
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.]
That is my recollection as well.
- open content on data staging
[What does that mean?]
I am not sure of the context of this note, but "open content on Foo" is synonymous with "presence of xsd:any of some sort in Foo". :-) I was asking that these extension spots remain in the staging elements so that we (Globus) could, for example, insert some extended metadata to use this with GRAM and not lose any functionality.
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?]
I brought this up in relation to extensions, but I am not 100% positive it could not apply to basic JSDL terms as well. The essential problem with any complicated declarative syntax is whether all pieces are mandatory or not. There is a common idiom in extensible languages to be able to mark some fields to this effect, perhaps using mandatory as the default and having an extra optional bit to override the default. The LDAP protocol is a nice old-fashioned version of this. Being able to mark some elements as mandatory and others as optional means that a consumer, for whatever reason, can filter out optional pieces and consider the remaining document as "equivalent" for the needs of the producer. This allows the consumer to eliminate extensions that it does not understand as well as parts it understands but which conflict with its own policies. Conversely, anything marked as mandatory that is not understood or welcome will have to lead to "failure", whatever that means in the usage context. The consumer knows that it cannot fully support, for whatever reason, the declarative bits that the producer thinks are essential to the meaning of the document as a whole.
- [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 understanding was that we would provide an 80% solution in the form of an executable application type where these limits would now live. I wasn't sure whether the base spec. would include any other application type, or just expect them to arrive via extension.
- 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?]
Yes, I think this is a good example and the way we discussed it in Seoul, the solution is to make two terms that explicitly capture the concept at the two different scopes. Something like: jsdl:TotalPhysicalMemory jsdl:PerResourcePhysicalMemory If we can find a prefixing scheme we all can tolerate, I would suggest modifying EVERY term to explicitly state its scoping in its name. No matter how certain we are that a particular term's scope is obvious, somebody out there will think the opposite. :-) karl -- Karl Czajkowski karlcz@univa.com