On Mar 30, Christopher Smith loaded a tape reading:
Given that JSDL is defining an ontology of terms so that we can all understand what is meant by "command line" or "file transfer", isn't the determination of mandatory or optional a bit out of scope? I can easily see a system based on negotiation where the two parties agree on which terms are consumable by the end system, so you can get this behaviour that way.
I guess I just worry that the user of JSDL's expectations for a particular job submission behaviour are met. Wouldn't it be nice to know if a particular attribute is rejected or not? This seems to me to be part of the submission protocol layer.
-- Chris
Yes, I guess I can buy that. It is a fine line, indeed, between trying to capture the meaning of the job and negotiating about variations on it. I think what was concerning me, while I had on a declarative-job-language hat, is that I expect the extensions mechanisms to be used out their in a world where types and specifications are not introduced in a coordinated fashion. Whether I can understand the meaning of a JSDL instance depends on whether I am aware of all the extension specifications the producer has used. I agree that this might be enough, and it is up to the enclosing protocol context to determine how one filters, projects, negotiates, or otherwise communicates the "important" job information from a particular producer to a particular consumer. From that point of view, critical/non-critical is a particular communications idiom used to increase the probability of such communication succeeding in heterogeneous environments. Sorry for the red herring... karl -- Karl Czajkowski karlcz@univa.com