Hi, Thanks for all the responses. It is in a way heartening to see this both from a participation perspective and with respect to my sanity. I was uncomfortable with the way the EMS discussion going with trying to "nail down" something without having any wood to nail to. I thought I was seriously missing something and decided to go with the "flow". I also had this uncomfortable feeling that my attempts to do the right thing were being misunderstood by some. I think we are not ready from "a reasonable agreed upon architecture" to the "candidate set of specs for a profile". I also thing the value of OGSA is from defining the architecture which acts as the scaffolding for the many specifications that are each being developed with a narrow focus (not bad in itself since that is their stated purpose). These specifications for the most part are "works in progress" and one or two that are ready or close to ready do not make a profile for an areas like EMS. We are also not agreed on the concepts in the architecture as the current exercise in re-labeling the concepts indicates. We have a strawman but more work is necessary to vet the architecture. On the other hand, we have implementations (or implementations in flight) in and around this space. From what I know/understand most are capable of scheduling execution but not managing execution. I am, therefore, uncomfortable basing the architecture definition on a few examples which could leave out other legitimate examples. We need to drive more participation and arrive at a desired architecture. This activity need not take a long while and can be in parallel to activities going on in candidate specs. Also as more implementations adopt some of these lower specs we will have more data points. I wanted to add my 2 cents to this discussion. It looks like we may want to modify the agenda to discuss the issues raised. ??? Talk to you later today. Ravi -----Original Message----- From: Christopher Smith [mailto:csmith@platform.com] Sent: Monday, January 17, 2005 11:48 AM To: Fred Maciel; 'David Snelling'; Hiro Kishimoto Cc: 'Ian Foster'; Subramaniam, Ravi; ali@epcc.ed.ac.uk; andreas.haas@sun.com; andreas.savva@jp.fujitsu.com; asm100@doc.ic.ac.uk; D.Snelling@fle.Fujitsu.com; darrenp@cadence.com; dejan@hpl.hp.com; flon@isi.edu; grimshaw@cs.virginia.edu; hornwp@us.ibm.com; jian@xcerla.com; jon.maclaren@man.ac.uk; naber@man.poznan.pl; nitzberg@pbspro.com; 'OGSA-WG'; pruyne@hpl.hp.com; Rajic, Hrabri; ramin.yahyapour@udo.edu; Scott.Jackson@pnl.gov; sjn5@doc.ic.ac.uk; tkojo@mvi.biglobe.ne.jp; troney@ncsa.uiuc.edu; Uwe.Schwiegelshohn@udo.edu; v.sander@fz-juelich.de; Wolfgang.Ziegler@scai.fraunhofer.de Subject: Re: [ogsa-wg] OGSA-EMS Meeting Agenda (2005-01-17) On 17/1/05 10:57, "Fred Maciel" <fred-m@crl.hitachi.co.jp> wrote:
3) A Job Management WSDL spec - would be nice, but to do it right we need WSDM first.
How about JSDL? Works without WSDM (but yes, should work better with
WSDM).
JSDL is not intended to be a document format to encapsulate job state. It is very clearly focused on the definition side of things. Other document formats and manageability interfaces will be required for job management. Basing this on WSDM seems to be the "right thing" to do. -- Chris