I have this theory, it's #2 of my "silly but possibly valid theories":- Any technology other than an RDBMS that implements a SELECT statement is inherently over-complex I would cite SLPv2 and that EJB query language [1] as two examples to back up my claim, with UDDI lurking nearby. I also note that it is badly escaped SQL select statements that are a primary attack point into custom HTTP apps, and even more often, custom SOAP endpoints [2]. There is something about the "let's do a SELECT" operation that gets people excited, but you soon end up with something that is hard to implement, test and interop test against, or you have to hand it off to a real DB underneath. Yes, bits of XPath fall in to this category too. If we are going to have select statements, at least be rigorous about requiring quotes around strings, for security reasons: “where (jobid = 'urn:guid:364') or (jobid = 'urn:guid:401')” -steve [1] http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBQL5.html [2] http://ws.apache.org/axis/java/security.html Paul Watson wrote:

Ian,

I agree that this is good progress. So let’s bank that and see if we can we can agree on one more thing, and then I’ll ask a question.

Considering your list of abilities (a, b & c) below, do we agree that in terms of expressiveness, the ordering is:

c>b>a

i.e. using approach c, a client can request operations on:

a) single jobs: “where (jobid = urn:guid:364)”

b) sets of jobs: “where (jobid = urn:guid:364) or (jobid = urn:guid:401)”

If there is agreement on this, then we could move on to discussing why it is felt necessary to provide more than just c for the job submission service.

Regards

Paul

Ian wrote…

...

Savas:

...

...

It seems that we are in agreement, then, that we want the ability to:

...

...

a) Request operations on individual jobs identified by some sort of "jobid"

...

...

b) Request operations on sets of jobs identified by a user-supplied list of "jobids"

...

...

c) Request operations on sets of jobs identified by more abstract criteria

...

...

We also agree that (as I expressed in the email that started this discussion) such >requests can be expressed in a few different ways, with somewhat different >characteristics.

...

...

That's progress I hope.

...

...

Ian.

* From: * Ian Foster [mailto:foster@mcs.anl.gov] *Sent:* 05 April 2005 17:59 *To:* Savas Parastatidis; Steve Loughran *Cc:* Mark McKeown; Karl Czajkowski; Dennis Gannon; Samuel Meder; ogsa-wg; dave.pearson@oracle.com; gray@microsoft.com; humphrey@cs.virginia.edu; grimshaw@virginia.edu; aherbert@microsoft.com; gcf@indiana.edu ; mark.linesch@hp.com; Frank Siebenlist; Tony Hey; Dave Berry; Paul Watson *Subject:* RE: [ogsa-wg] RE: Modeling State : Technical Questions

[I'm feeling increasingly bad about sending email to all of the people CCed here, who may not be interested in these issues at all but got addressed by Tony long ago...]

Savas:

It seems that we are in agreement, then, that we want the ability to:

a) Request operations on individual jobs identified by some sort of "jobid"

b) Request operations on sets of jobs identified by a user-supplied list of "jobids"

c) Request operations on sets of jobs identified by more abstract criteria