- jsdl-wg - lists.ogf.org

my view on "user credentials"
by Karl Czajkowski 30 Mar '05

30 Mar '05

I don't disagree that user credentials will be important for many jobs. However, I disagree that a type and semantics-free UserCredential field, as in the current draft, actually helps. I think a consumer of a JSDL document needs to know two things to make use of credentials: 1) what is it, and 2) what is it for. I think it is wishful thinking to say there is one generic user credential category and the consumer can divine the rest from the value itself. If this is so, we might as well put this expressive value in the xsd:any##other slot as an extension (understood by some, but not all, consumers). For example, in WS-GRAM for GT4, we do not pass around credentials per se, but we do pass around references to credentials (the actual credentials are moved ahead of time by out-of-band means relative to WS-GRAM). Because each of these references is of the same type (and referring to the same type of credential: our GSI proxies), we have separate fields in the WS-GRAM job language to designate the purpose of each one: one to put in the job's environment (as a file), one for WS-GRAM to use when invoking our RFT file transfer service, and a third to pass through (by reference) to the RFT service itself (which it then uses to authenticate with GridFTP). We would have to use these wrappers in the JSDL transliteration, since "user credentials" is too abstract to actually convey the different meanings we have. I suspect that any meaningful "pass through" would have to do the same thing---designate _which_ target mechanism to pass the values to. It wouldn't help much if a JSDL consumer "passed" a Kerberos ticket in the file where we expect GSI proxies, or vice versa. karl -- Karl Czajkowski karlcz(a)univa.com

4 5

REPOST: Topics for the upcoming phone conference
by Michel Drescher 29 Mar '05

29 Mar '05

REPOST: Identical to the first attempt except the spec doc. The first mail seemed not to pass the ML software. Please obtain the JSDL specification document from Gridforge. ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP ---------- Dear JSDL wranglers, this is a list of topics I would like to be decided on at the today's phone conference. (1) JobDefinition/@JSDLVersion attribute The version of the JSDP spec is uniquely defined elsewhere, and encoded in the namespace. I do not see any use of this attribute. (2) JobDefinition/JobIdentification/User/UserCredential The spec contains a comment that this element "... can be handdled through the standard extension mechanism." Let's decide on the phone conference to keep it or to drop it (and release it to the extension mechanism). (3) range values Karl and Stephen made a valuable proposal for a clear and efficient definition of range values: <lowerBound>xsd:integer</lowerBound> ? <upperBound>xsd:integer</upperBound> ? <exact>xsd:integer</exact> * <range> <lowerBound>xsd:integer</lowerBound> <upperBound>xsd:integer</upperBound> </range> * I propose to replace our current definition of a range value with this complex structure. (4) xsd:integer or xsd:double Partly touching topic 3, there's a discussion on wether to use integers or fraction numbers. I propose to use xsd:double together with an optional attribute "epsilon=xsd:double" for precision restrictions, changing the range type to <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound> ? <upperBound epsilon="xsd:double"? >xsd:double</upperBound> ? <exact epsilon="xsd:double"? >xsd:double</exact> * <range> <lowerBound epsilon="xsd:double"? >xsd:double</lowerBound> <upperBound epsilon="xsd:double"? >xsd:double</upperBound> </range> * (5) (Non-)Critical extensions There's a discussion at the moment to tag particular elements of JSDL to be (non-)critical in terms of understandability and support, similar to the SOAP attribute "mustUnderstand=xsd:boolean". I propose to postpone this mechanism to after the first official JSDL release. (6) naming elements To promote reusage, elements of JSDL documents should be identifiable. An appropriate technique is using QNames. This requires the elements that we want to be reused to get a naming attribute of type xsd:NCName. I propose to use this technique to promote reusage. If we agree to use this, a follow-up action point will be assiged to identify the elements that need this new naming attribute and to propose a naming syntax. (7) Resource constraints global total and/or per process During GGF13, the issue came up that a resource can be defined to be total global or as per process. A use case may be to constrain a job to 10 Gigabytes of physical memory and at the same time to constrain the job's processes to consume no more than 10 Megabytes of physical memory. I propose to reflect this in JSDL expressis verbis rather to punt it out to an extension. If we agree on incorporating this, a follow-up action point will be the investigation and proposal of solution alternatives. (8) Comments and flames on the current specification document Although this is very short term, I attached the current latest version of the spec document - unofficial as I am not the official editor! - in which I tried to reflect all the changes we agreed on at GGF13. It was quite much, so expect to face errors in what I created. Cheers, Michel

2 1

JSDL: Spec cleanup
by Ali Anjomshoaa 29 Mar '05

29 Mar '05

Hi all, thanks to Michel we have a cleaner version of the spec following GGF13 with some of the issues answered. Michel still has the pen and will be bringing an issues list to today's telecon. The spec is at: https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/e… I propose that any outstanding issues from GGF13 be added to the spec, incrementing the double digits at the end of the version number at each iteration for this purpose. i.e. 0.9.5-00 to 0.9.5-01 etc. Any new additions to the spec (will have to get past Darren first [good luck!] 8^) ) should increment the last digit of the version number, i.e. 0.9.6 next. Cheers and take care, Ali Michel, pen goes to Andreas at the end of today for him to review the spec on the flight back home :) (The movies on the flight back to Tokyo are not great, I checked them out). -- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali(a)epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------

2 1

FW: JSDL Meeting
by Bill Harris 29 Mar '05

29 Mar '05

William Harris Program Architect Oryx follow me - 800 281 6462 Inside cadence 88 202 6462 Cell Phone 801 301 2744 You have been invited to attend a Microsoft Office Live Meeting. At the time of the meeting, click on the following link to attend. http://www.placeware.com/cc/cadence/join?id=RWZ334&role=attend Subject: JSDL Meeting When: Tuesday, Mar 29, 2005 8:00 AM (MST) Scheduled to Occur: Once Duration: 1 Hour 30 Minutes Audio Information: 1-800-933-3594 ext 3000 pin: 6444 Click to add to your Outlook calendar: http://www.placeware.com/cc/cadence/meetingICS?id=RWZ334&role=attend&i=i .ics Alternate Attend Instructions: Go to: http://www.placeware.com/cc/cadence/join Your Name: (enter your name) Meeting ID: RWZ334 Dial In Numbers >Phone Numbers: >Belgium - 0800-7053 >Bezeq - 1-800-940-1786 >France - 0800-903109 >Germany - 0800-1815765 >Hong Kong - 800-968932 >Italy - 800874509 >Japan - 00531123656 >Korea-Tele - 00798-14-800-0512 >Netherlands - 0800-0225447 >Singapore - 800-1200766 >Sweden - 020-7905043 >Taiwan - 00801-13-8546 >UK - 0800961294 >US - 800-933-3594

2 1

drop User section?
by Karl Czajkowski 21 Mar '05

21 Mar '05

I had a thought on the flight home... isn't the user and group naming really part of the POSIX executable-application type, just like the limits turned out to be? [A side comment is that they are mislabled for POSIX: userName should be a string, and UserID if it exists should be a number, etc.] If we move them to the type-specific App syntax, the User section would become empty (since we already scoped away the userCredential element). I would advocate doing this and "garbage collecting" the User element from the spec 1.0, but I am certain I do not understand others' use cases surrounding this element. Any thoughts? karl -- Karl Czajkowski karlcz(a)univa.com

2 1

range value type
by Karl Czajkowski 19 Mar '05

19 Mar '05

Before I left Seoul, Stephen showed me a simple solution that was structurally along the lines of what I imagined for the range value element type. RANGE-VALUE COMPLEX TYPE PSUEDO-SCHEMA ---------------------------------------- It is very straightforward in terms of writing XSD. With some changes I recommend, it would look like this as a sequence: <...> <lowerBound>xsd:integer</lowerBound> ? <upperBound>xsd:integer</upperBound> ? <exact>xsd:integer</exact> * <range> <lowerBound>xsd:integer</lowerBound> <upperBound>xsd:integer</upperBound> </range> * </...> I have changed the names of the pieces from what I think Stephen showed me, in order to try to make their meaning as obvious as possible. The whole element is more or less a disjunction of its expression parts, but please note below the special treatment of the optional semi-space constraints (the top-level lower/upper bounds)... they are treated identically to a regular range element if both are specified and only act as true semi-spaces when one is omitted. However, all other exact and range expressions are treated independentally (as a true disjunction). The alternatives to this that I came up with all seemed unsatisfactory: 1) make it a complete disjunction, meaning any value over the lower bound OR under the upper bound is in range. 2) other hybrid conjunctions, meaning multiple bounds, ranges, and/or exact expressions have to match. INTEGER OR FLOATING-POINT REPRESENTATION ----------------------------------------- We had discussed using xsd:integer and this implies that any use of this type must just define the "base" units that are being counted. The only problem in our base terms is (cpu-)time, where I wonder if we are better off using a floating-point type to allow the base units to be seconds and still allow fractional second specification. Choosing some specoific fractional second as the base unit seems unappealing to me. If we provide a floating point/fractional version, I think there needs to be an optional attribute on the exact element to specify a precision or epsilon value for equality tests, e.g. <exact jsdl:precision="0.001">3.1415927...</exact> could match anything in the range (3.1405927..., 3.1425927...). Or, the consumer could treat it as undefined and do something appropriate if a precision is specified which it cannot support. Perhaps a simpler solution is to stick with arbitrary length integers and add an optional divisor attribute that defaults to 1: <exact jsdl:divisor="100000">314159</exact> which would be exactly 3.14159 in decimal fractions? Of course, a different divisor like "1024" could be used for binary fractions. I am not a numerical analyst so I would prefer we bounce any such proposal off of several before adopting it. SEMANTICS ------------------------------------------ The matching semantics would be as follows for an element of this type: let boolean "L" and "U" be whether lower/upper bound values are specified; let integer "l" and "u" be lower/upper bound values respectively let E be { e | e is specified in an exact element } let R be { <l,u> | <l,u> is specified in a range element } in_range(x) = (!L || l <= x) && (!U || x <= u) || there exists e in E such that x = e || there exists <l,u> in R such that l <= x <= u. INCLUSIVE VERSUS EXCLUSIVE RANGES ----------------------------------------- Also, I suggest that we place an optional attribute in the boundary elements: jsdl:exclusiveBound=xsd:boolean with default false, meaning that by default the range of acceptable values includes the boundary value in the element body. Setting it to true would mean that the boundary value is not part of the range. This supports any meaning captured before in the operator enumeration, I think. A minor note is that the elements have to appear in the sequence order, which I argue is a good thing for machine-machine communication as the parse tree will yield three monomorphic arrays of values with clear meanings, rather than one polymorphic array that the consumer has to traverse. karl -- Karl Czajkowski karlcz(a)univa.com

2 2

GGF13 Sessions' notes, Spec and Schema
by Ali Anjomshoaa 16 Mar '05

16 Mar '05

Andreas, all, The spec with comments and notes are now on GridForge under the GGF13 folder. The latest version of the Spec in under Session4 - clearly some tidying and refactoring required to make comments global etc. Many thanks for everyone's extremely useful input at the meeting. Hope you all stay tuned to help finish v1.0. Cheers and take care, Ali -- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali(a)epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------

1 0

XSD Schema - latest
by Andrew Stephen McGough 16 Mar '05

16 Mar '05

All, Here is the latest XSD schema. Think I've got all the new stuff in that people wanted. I'll add it to sourceforge. steve.. -- -- ------------------------------------------------------------------------ Dr A. Stephen McGough http://www.doc.ic.ac.uk/~asm ------------------------------------------------------------------------ Technical Coordinator, London e-Science Centre, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8409 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------

5 9

this is just a test message
by Gene Rackow 14 Mar '05

14 Mar '05

testing testing.

1 0

jsdl specification 0.9.3. (draft 14)
by Andreas Savva 10 Mar '05

10 Mar '05

I uploaded a new version of the spec. with a number of additions and changes. Some are editorial; some content. Changes: - Moved IP statement to the back per GFD template - Adjusted style of appendices - Adjusted style of back end sections - Adjusted style of TOC - re-arranged sections - Minor changes to fix pseudo-schema multiplicity (missing '?') - Added a couple of references - Added pseudo-schema appendix (do we want to keep this or not) (michel) - added new units (michel) - added arguments/argument (michel) - added limits (donal) - changed id to sid (schema and spec need cross-checking) - added 'name' attribute to FileSystem - removed redundant 'Description' sections & changed name of jsdl:description type elements to Description in the spec (this was agreed some time back.) - added newer schema at the back. This is the one from gridforge and so not the absolute latest one yet. - added a first draft for the processtopology section; https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/e… -- Andreas Savva Fujitsu Laboratories Ltd

3 5