Guys, here're my comments to this thread: On 3 Apr 2005, at 10:53, Donal K. Fellows wrote:
Ian Stokes-Rees wrote:
Numerical Operators: It is not at all clear to me what the following sentence or the example XML are supposed to indicate:
I think we could probably just drop that subsection entirely. The range scheme covers just about everything useful that isn't obscenely complex.
I second that. I think it's a left over from earlier versions of the spec.
ExecutionGroupID, Hostname (and others bits): These seem to go against the idea that you are not going to support security aspects in JSDL, but then the user can assert groups or hostnames which may require a particular authorization token in order to access or complete the request. Something will need to provide a mapping which says "Use this token to be able to exec in group X or on host Y", don't you think?
We used to have this mechanism (called Profiles) but we removed it. It belongs in the scope of other specs (e.g. WS-Agreement).
Donal, I think you missed what Ian said here. Profiles were not meant to provide different security tokens the way Ian outlined it. At least, they were not designed having that in mind; but they were certainly (ab)usable that way. :^) I think Ian meant something different: While JSDL claims to be a job dcescription language striving to scope out security issues (which we did not always do) there're still security related issues creeping in like ExecutonUserID. Well, IMHO I'd like to follow the "clean trail of purity" and kick these things out, bbut yu always have to consider the trade off between purity and usability. Vulgo, have a nice pure document that nobody will use or have a document that has its stains but is incredibly popular. :^) Also take in mind that standardised documents always represent comppromises on all ends of it. That's the inherent nature of standardisation bodies. :^)
jsdl: namespace prefix: In the examples, sometimes it is used and sometimes it isn't. If there is a reason for that, it isn't clear to me.
That's a clean-up task to be done. ;-) Have you raised it as a tracker item on GridForge?
It also has something to do with the style elements and types are defined in the schema. We need to find a stringent way with this.
Final comment: it would be nice to have a single tabular summary of all the "elements" in JSDL along with:
That'd be nice, but it is something for a non-normative appendix and should only be done with a tool starting from our final-candidate schema. Or it could go in a Primer doc, of course.
I agree to that one, too. Cheers, Michel