April 2005 - jsdl-wg - lists.ogf.org

Issues for todays phone conference
by Michel Drescher 19 Apr '05

19 Apr '05

Folks, here's a list of issues. It's huge in numbers, but most of it is (IMHO) quite quickly fixable. 1) Fig. 1 revision 2) Fig. 2 revision 3) Prefixes and namespaces (check and update) 4) Namespace should be in the table (and update) 5) Section 3 (spec doc) general revision and polishing up 6) Update explanation for jsdl:other usage 7) Possibly reformat ch. 4.2.1 8) JSDL compliance levels How much of jsdl a system must support, not just process. Probably a topic for later. 9) The statement "If not supported then the consuming system MUST reject the document." needs a bit more explanation or re-write. 10) When/why did HostName change from 0-1 to 0-n? (reverted) 11) Filesystem name and type and filesystem reference in DataStaging 12) Mountpoint environment variable. Is the current approach ok, or should we provide a separate mechanism, e.g, a tag that if present provides the name of the environment variable in which the MountPoint value must be present. 13) Should FileSystemID be changed (back) to FileSystemName. 14) DRMAA use case for defining filenames. We have to at least be able to show an example of how to define and stage out an <Output> file. 15) CreationFlag. Was this made optional or not? Confirm and delete comment. 16) Process Topology needs review. In particular are the examples ok or not, are the definition correct and so on. Delete the yellow comments once that is done. Not sure if we should define the precise allocation behaviour or allow for that to be defined instead. 17) Section "Extending JSDL" needs an owner. I expect this section to be about 1 page long so should not be too much trouble. 18) Normative Extension is out of place 19) re-check terminology for process topology and delete comments 20) "Bytes (octets of bits)" 21) Memory limit incomplete text 22) pipe size limit incomplete text 23) Update of security considerations in line with latest decisions (when we actually reach firm decision) 24) Complete author information (see my entry as reference) 25) Update contributors and acknowledgements 26) Complete list of Normative references, e.g., CIM is still missing. 27) Glossary owner 28) Translation tables need to be added Proposal: Karl for Globus/GRAM, Chris for LSF, Saga-san for Naregi, ??? for Condor, ... 28a) Put the translation tables into a separate document? 29) Promised examples for the appendix (But maybe this should be split off into a Primer) 30) Make citations in text of document reference real cross-references. 31) Complete example sub-sections --- For those that read until here: Is anything missing? Cheers, Michel

7 20

Issues for All to Comment on
by Donal K. Fellows 19 Apr '05

19 Apr '05

The following issues (from the last telecon) need comment from multiple people; please feel free to jump in with anything you want to say on these topics. 12) Mapping mountpoints to environment variables (see spec 5.5.12) 16) Process topology section needs review 32) POSIXApplication/Executable cardinality (=1 vs <=1) On issue 32, my feeling is that having the Executable as optional is a good thing since this permits the processing engine to derive the executable name from the overall application name and version. I've known the same application be installed with multiple different names across multiple architectures within the same overall organization, some of which are non-trivial to guess[*], so concealing that sort of stuff from users is a distinctly good thing in my view. (Very few users want to know, and sometimes there are details of the job running process which we would prefer them not to see either.) Does anyone strongly disagree on this point re cardinality? Donal. [* Both Gaussian and Amber are nasty, but in different ways. ]

3 2

JSDL: Telecon minutes
by Ali Anjomshoaa 18 Apr '05

18 Apr '05

Hi all, the minutes of yesterday's telecon are on GridForge: https://forge.gridforum.org/projects/jsdl-wg/document/Minutes_-_2005-04-13/… Those on the call, you can find your actions in-lined in the minutes. Please ask for help with your actions if you don't have time or need input. Target someone you know is able to help and perhaps has time. Catch you on the call next Tuesday, when we can tick off a few more issues. Cheers, 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 1

FW: Madeline Pulsipher
by Bill Nitzberg 18 Apr '05

18 Apr '05

Subject: Madeline Pulsipher From: "Darren Pulsipher" <Darren.Pulsipher(a)xango.net> To: "Ashlee Rich" <Ashlee.Rich(a)xango.net>, "Stacy Pulsipher" <stacy(a)pulsipher.org>, <jsdl-wg(a)ggf.org> Madeline joined this world at 12:21 pm on Sunday April 17,2005. 7 lbs 11 oz. 20 inches long. She looks like her older sister did which means we will have another beautiful little girl in our family. Mommy and daughter are doing great and will be home soon. Darren

1 0

Madeline Pulsipher
by darren＠pulsipher.org 18 Apr '05

18 Apr '05

Madeline joined this world at 12:21 pm on Sunday April 17,2005. 7 lbs 11 oz. 20 ½ inches long. She looks like her older sister did which means we will have another beautiful little girl in our family. Mommy and daughter are doing great and will be home soon. Darren

1 0

RE: [jsdl-wg] Any JSDL parser around
by Vivian Li 15 Apr '05

15 Apr '05

Hi, Try if this works? <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="xxx" targetNamespace="http://xxx" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" <wsdl:types> <xsd:schema targetNamespace="http://xxx"> <xsd:include schemaLocation="xxx/jsdl.xsd"/> </xsd:schema> </wsdl:types> </wsdl:definitions> name the above codes into xxx.wsdl, then pass to Axis. you need to replace xxx with proper ones. You could also give it a package name where you want the classes to be generated when you tool it. Regards, Vivian > -----Original Message----- > From: owner-jsdl-wg(a)ggf.org [mailto:owner-jsdl-wg@ggf.org] On Behalf Of > Aleksandr Konstantinov > Sent: 15 April 2005 12:46 > To: jsdl-wg(a)ggf.org > Subject: Re: [jsdl-wg] Any JSDL parser around > > It seems Axis can't digest jsdl.xsd. Any suggestions on how to convert it > to wsdl (if possible at all)? > > > A.K. > > > > On Fri, 15 Apr 2005 13:11:05 +0200 > Roger Menday <r.menday(a)fz-juelich.de> wrote: > > > > > On Fri, 2005-04-15 at 11:11 +0100, William Lee wrote: > > > When you say a parser, do you mean a XML-to-Object binding for JSDL > > > schema? JSDL is specified in XML, therefore any XML tools (e.g. DOM4j, > > > JDOM, JAXB in Java) will do the job. > > > > In java, I'm currently using xmlbeans, http://xmlbeans.apache.org/ for > > this kind of thing. IMHO the XML schema support is unparallelled. It > > eats the JSDL.xsd with no problems ! I guess everyone has their > > favourite in such matters though. > > > > Roger > > > > > If you are looking for a JSDL > > > consumer, Imperial College has a project called GridSAM > > > (http://www.lesc.ic.ac.uk/gridsam) which translates JSDL into > > > DRM-specific (e.g. Condor, SGE) actions. UCL has a project for > > > translating JSDL into Condor ClassAds. > > > > > > William > > > > > > Aleksandr Konstantinov wrote: > > > > > > > Hello JSDL gurus, > > > > > > > > Does anybody know any common purpose JSDL parser implementation? Or > project which is going to release such? > > > >Preferably with C/C++ API. > > > > > > > >Thanks, > > > > > > > > > > > >A.K. > > > > > > > > > > > > > > > > > > > >

2 1

Any JSDL parser around
by Aleksandr Konstantinov 15 Apr '05

15 Apr '05

Hello JSDL gurus, Does anybody know any common purpose JSDL parser implementation? Or project which is going to release such? Preferably with C/C++ API. Thanks, A.K.

4 7

Re: [jsdl-wg] Any JSDL parser around
by Chee-Kian Koh 15 Apr '05

15 Apr '05

Hi William, GridSAM looks cool! What DRMs support now? Will we see one for Grid Engine soon? > On Fri, 15 Apr 2005 11:11:44 +0100 > William Lee <wwhl(a)doc.ic.ac.uk> wrote: > > > > > When you say a parser, do you mean a XML-to-Object binding for > JSDL > > schema? JSDL is specified in XML, therefore any XML tools (e.g. > DOM4j, > > JDOM, JAXB in Java) will do the job. If you are looking for a > JSDL > > consumer, Imperial College has a project called GridSAM > > (http://www.lesc.ic.ac.uk/gridsam) which translates JSDL into > > DRM-specific (e.g. Condor, SGE) actions. UCL has a project for > > translating JSDL into Condor ClassAds. > > > > William ----------------------------------------- Melvin Koh Chee Kian Grid Research Engineer Asia Pacific Science & Technology Center Sun Microsystems Inc. Website: http://apstc.sun.com.sg/ -----------------------------------------

1 0

Naming elements
by Michel Drescher 14 Apr '05

14 Apr '05

Folks, from the last phone conference, I had the action assigned to follow the suggestion of naming elements. Based on some thinking and toying around, I propose the following layout: JSDL allows to define a) applications that are supposed to be executed, b) sets of resources that are to be consumed, c) files to be staged in and out and, finally, d) establishes associations between applications, resources and data sets. An exhaustive 3-tuple of associations is called "JobDescription". A JobDescription can also contain a set of identifiable elements serving various kind of purposes, such as accounting, billing, etc. These elements are aggregated in an element called "JobIdentification". All this is aggregated in a root element called "JobDefinition" (a name I would like to question, but more on this at a later point). This short description from a bird's eye view may not be totally new, but it gives some valuable hints on what is worth being referencable and what not: a) resources, b) applications and c) data sets. A JobDescription does not necessarily has to be referencable, since it is usually a unique association between other elements that, in this configuration, serve a unique purpose. It is adequatically specified through the document's namespace. Similar jobs (who have a different namespace) may want to use exactly the same set of resources or the same application etc. Most likely, however, the resource sets or applications etc. that have been defined for another job will not fit exactly the new job's needs, so a mechanism to tweak existing definitions could be handy. So, more technically and closer to the spec/schema, the following elements should be made referencable: - /JobDefinition/JobDescription/Application - /JobDefinition/JobDescription/Resource - /JobDefinition/JobDescription/DataStaging - Additionally, a similar mechanism exists for /JobDefinition/JobDescription/Resource/FileSystem and /JobDefinition/JobDescription/DataStaging/FileSystemID. I also propose to change FileSystemID to the type xsd:QName. - Following the convention used with the construct "xsd:group", I propose to use an attribute "name" of type "xsd:NCName" to make an element referencable. An attribute named "ref" of type "xsd:QName" is proposed to be used as a reference to a referencable element. - Sibling to JobDescription, applications, resource sets and data staging elements are allowed to be specified. They all get an attribute "name" of type "xsd:NCName" to be made referencable. - JobDescription defines local elements(!) with the same name (for applications, resource sets and data staging) and each gets an optional attribute named "ref" of type "xsd:QName" to refer to already defined elements (either in the same document, or externally). - These locally defined elements allow exactly the same appropriate groups of elements as the elements sibling to JobDescription. - Elements specified in JobDescription's local elements override elements with the same name in referred elements. - Finally, I propose to change the name of "JobDefinition" to something else, e.g. "JSDL" or something that does *not* have "Job" in its name since it does not define jobs alone anymore. (I just have no clue on a reasonable replacement.) The following proposals are of more concern to schema hackers and are related to technical issues of design and "taste". They can easily be skipped by others although they may touch higher level concerns: - I further propose to follow one of the two scenarios: a) define exactly one global element ("JobDefinition") so that any valid JSDL document always has "JobDefinition" as root element b) define a limited number of global elements, i.e. JobDefinition, JobDescription, Resource (rename to "ResourceSet"?) Application and DataStaging so that any valid JSDL document may have any of these globally defined elements as root element - Any other elements and types should be locally defined. Or do we want to allow i.e. "jsdl:NetworkBandwidth" to be root element? - Use xsd:group to group elements together and refer to these groups instead of repeating element definitions Cheers, Michel

4 12

JSDL 0.9.5-02 uploaded
by Andreas Savva 14 Apr '05

14 Apr '05

I have uploaded JSDL spec. 0.9.5-02 and corresponding schema files to gridforge. This release contains a number of changes, mainly by Michel, especially around limits as well as the rangevalue definition and explanation. Also the POSIXApplication is now split off into a separate schema. ** This is a snapshot release so it is known to have inconsistencies ** and inaccuracies. Use at your own risk. The plan is to go back to releasing a snapshot every week (or bi-weekly if there are insufficient changes) ideally before each call. People with text assignments please send me, or the list, your updates to this version in time for me to put things together. Ali when releasing the previous version said: > 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. I've kept the numbering scheme for this release (note that -01 was never formally released) but I would like to propose instead to start calling the spec "JSDL version 1.0, draft XX" where the XX corresponds to the version number of the document on gridforge. E.g., this release would be "JSDL version 1.0, draft 17." URLs: https://forge.gridforum.org/projects/jsdl-wg/document/draft-ggf-jsdl-spec/e… https://forge.gridforum.org/projects/jsdl-wg/document/jsdl.xsd/en/8 https://forge.gridforum.org/projects/jsdl-wg/document/jsdl-posix.xsd/en/1 Equivalent shorter urls: http://tinyurl.com/3taa2/draft-ggf-jsdl-spec/en/17 http://tinyurl.com/3taa2/jsdl.xsd/en/8 http://tinyurl.com/3taa2/jsdl-posix.xsd/en/1 -- Andreas Savva Fujitsu Laboratories Ltd

1 0