November 2007 - jsdl-wg - lists.ogf.org

JSDL Teleconference - 28 November 2007 @1pm UTC
by Andreas Savva 02 Dec '07

02 Dec '07

Confirming a call Wednesday, 28 November at 1pm GMT. Proposed agenda: - Updates, if any, on - JSDL 1.0 Errata - XQuery extension - Activity schema requirements discussion (cont.) - scope of work - UDAP document available? - Other business ===== Full call-in details ==== Date: 28 November 2007 Time: UTC/GMT 1:00 PM / EST 8:00 AM / PST 5:00 AM / JST 10:00 PM Duration: 1 hour Dial-in numbers (toll): US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 207 3655269 (London) Japan: +81 3 3570 8225 (Tokyo) Other countries: http://tinyurl.com/eg48j User guide: http://tinyurl.com/qknrf Teleconference participant PIN: 4371991 Screen share: http://jsdl.glance.net/?key=1128 Note: When you dial in after the initial message in English for the PIN there is another message in Japanese only (sorry) to state your name and press '#' in order to join the call. -- Andreas Savva Fujitsu Labs. Ltd

5 4

Teleconference minutes - 28 November 2007
by Andreas Savva 28 Nov '07

28 Nov '07

Minutes are on gridforge. https://forge.gridforum.org/sf/go/doc14944?nav=1 -- Andreas Savva

1 0

Re: [jsdl-wg] Wildcards in data staging elements
by Bernd Schuller 14 Nov '07

14 Nov '07

Hi, thanks for your replies! Alexander Papaspyrou wrote: > > IMHO this is more or less a convenience feature: instead of writing a > staging element for each of "outfile1.dat" to "outfile100.dat" by > hand, there should be an easier way to do it. But this is something > that should be handled by the UI used for submission, and (stab me if > I'm wrong) as such out of the scope of JSDL. A UI can't handle runtime resolution, for example. Say, your application produces an unknown number of image files "*.png" and you want all of them staged out. So it's not convenience alone. As a good functional example for filesets/wildcards, I'd again quote Apache Ant. Best regards, Bernd. -- Dr. Bernd Schuller | mail: b.schuller(a)fz-juelich.de | phone: +49 2461 61-8736 (fax: -6656) Distributed Systems and Grid Computing | personal blog: Juelich Supercomputing Centre | http://www.jroller.com/page/gridhaus http://www.fz-juelich.de/jsc | ----------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender) ----------------------------------------------------------------------------------------- -----------------------------------------------------------------------------------------

1 0

Wildcards in data staging elements
by Bernd Schuller 14 Nov '07

14 Nov '07

Dear jsdl folks, what is the opinion on using JSDL DataStaging elements that contain wildcards? Or even something more powerful such as filesets with includes and excludes, as in Apache Ant? Thanks and best regards, Bernd. -- Dr. Bernd Schuller | mail: b.schuller(a)fz-juelich.de | phone: +49 2461 61-8736 (fax: -6656) Distributed Systems and Grid Computing | personal blog: Juelich Supercomputing Centre | http://www.jroller.com/page/gridhaus http://www.fz-juelich.de/jsc | ----------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender) ----------------------------------------------------------------------------------------- -----------------------------------------------------------------------------------------

4 3

Minutes of 7 November 2007 and next call
by Andreas Savva 13 Nov '07

13 Nov '07

The minutes from last week's call are on gridforge. https://forge.gridforum.org/sf/go/doc14931?nav=1 Since SC'07 is this week and next week is Thanksgiving in the US our next call is scheduled for Nov.28. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

Validating JSDL documents
by Thomas Soddemann 06 Nov '07

06 Nov '07

Dear Group, within the DEISA project we have a new Web Service - SaaS project. With that we are faced with task of providing means for the interpretation of JSDL documents including its standard extensions. When working on this project, we naturally had a close look at the JSDL specification and the provided JSDL schema definitions (meaning JSDL 1.0 which we will refer to as the "core" XSD and the three extensions, POSIX, HPCPA, SPMD). Accepting JSDL documents means certainly verifying them syntactically and in a second step semantically. But due to the use of xsd:any and xsd:anyAttribute tags at various places in the core XSD, it is not possible to perform a syntactical verification of a document on the basis of the given schemata alone. Extra code is needed to check the correct position of elements from the extension name spaces. When reading the section of the specification which describes how to extend JSDL we got the impression that xsd:any and xsd:anyAttribute are used as hooks for extending JSDL. The problem implementors like us have now, is the extra code which is needed to check the validity of JSDL documents arising from the use of the any tags. More code means a greater risk of bugs. In addition this extra code may also lead to non-interoperable behavior due to misinterpretations of the specification document(s). Hence, should it not be the ultimate goal for the JSDL-WG to formulate a schema definition which allows extensions but also requires this extensions to inherit and adhere to the intended structure? Only then, it would suffice to perform a simple XSD validity check on a given JSDL document in order to determine its syntactical validity. We think, it is conceivable to modify the existing JSDL schemata to fulfill the above requirement with only minor modifications to the JSDL spec itself. First of all, JSDL core spec extensions can always extends JSDL elements, since none of them is marked as final. This already does enable extensions to define additional elements and attributes without the need of exploiting xsd:any and xsd:anyAttribute. Furthermore, it still should be possible to include serveral extensions (at least as sub-elements in Application, and may be also in JobIdentification, Resources, and DataStaging). This can be achieved by introducing an optional abstract element to these elements in a prototype pattern manner. An example for Application could be <xsd:complexType name="Application_Type"> ... <xsd:element ref="ApplicationPrototype" minOccurs="0" maxOccurs="unbounded"/> </xsd:complexType> which could be implemented as <xsd:complexType name="ApplicationPrototype_Type"> <xsd:sequence> <xsd:element name="application" type="ApplicationPrototype_Type" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="applicationRef" type="xsd:IDREF" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID" use="optional"/> </xsd:complexType> <xsd:element name="ApplicationPrototype" type="ApplicationPrototype_Type" abstract="true"/> Extensions like SPMD then would simply extend ApplicationPrototype <xsd:complexType name="SPMDApplication_Type"> <xsd:complexContent> <xsd:extension base="jsdl:ApplicationPrototype_Type"> <xsd:sequence> ... </xsd:sequence> <xsd:attribute name="name" type="xsd:NCName" use="optional"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="SPMDApplication" type="SPMDApplication_Type" substitutionGroup="jsdl:ApplicationPrototype"/> and an according JSDL document snippet still would read as <Application> <ApplicationName>Whatever</ApplicationName> <ApplicationVersion>1.1b</ApplicationVersion> <jsdl-spmd:SPMDApplication > <jsdl-spmd:NumberOfProcesses>128</jsdl-spmd:NumberOfProcesses> <jsdl-spmd:ProcessesPerHost>32</jsdl-spmd:ProcessesPerHost> <jsdl-spmd:ThreadsPerProcess>1</jsdl-spmd:ThreadsPerProcess> <jsdl-spmd:SPMDVariation></jsdl-spmd:SPMDVariation> </jsdl-spmd:SPMDApplication> </Application> but could be verified syntactically in simply using schemata. For achieving such a goal, a few steps would have to be done. * all occurrences of xsd:any and xsd:anyAttribute elements would have to be removed from the specification * the "Extending JSDL" section in the specification would have to be rewritten * the standard extensions would have to be augmented by adding inheritance to match the above structure * xsd:any and xsd:anyAttribute elements may be removed from the standard extension XSDs as well. Your comments on this are very welcome. Best wishes, Thomas

2 1

JSDL Teleconference - 7 November 2007 @1pm UTC **NEW TIME**
by Andreas Savva 06 Nov '07

06 Nov '07

***** NOTE NEW TIMESLOT***** This is to confirm a call tomorrow. Please note the new time of 1pm GMT. Full call in details, including timezone information, at the bottom of this email. Proposed agenda: - Activity schema requirements discussion (continued from OGF21) - JSDL 1.0 Errata publication - Other business ===== Full call-in details ==== Date: 7 November 2007 Time: UTC/GMT 1:00 PM / EST 8:00 AM / PST 5:00 AM / JST 10:00 PM Duration: 1 hour Dial-in numbers (toll): US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 207 3655269 (London) Japan: +81 3 3570 8225 (Tokyo) Other countries: http://tinyurl.com/eg48j User guide: http://tinyurl.com/qknrf Teleconference participant PIN: 4371991 Screen share: http://jsdl.glance.net/?key=1107 -- Andreas Savva Fujitsu Labs. Ltd

1 0