[jsdl-wg] GGF 13 notes and further discussion

[Karl Czajkowski]

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 at univa.com