You have a good point here Chris. I'm glad you're making your point and staying consistent with the views you expressed much earlier for JSDL :) We agreed at the telecon on Tuesday that we're leaving this discussion for post-v1.0, even post bug-fixes if we can. Cheers, Ali On Wed, 30 Mar 2005, Christopher Smith wrote:
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
On 29/3/05 01:30, "Ali Anjomshoaa" <ali@epcc.ed.ac.uk> wrote:
Hi Karl, Donal,
I think that the 'optional' vs. 'mandatory' attribute mark-up could work for JSDL. However, we decided a long time ago that all specified attributes in a JSDL doc MUST be satisfied, i.e. that there are NO attributes that a system MAY consider optional in a job description.
I think we should perhaps reconsider this position. However, I also think that this is something that we can leave for a post-v1.0 version of the spec. It doesn't strike me as something that will break version 1.0 backward compatibility if introduced at a later stage.
So, I would vote to postpone this issue until after v1.0 has been released and any bugs on that version are fixed.
Any thoughts on this?
Cheers and take care,
Ali
On Tue, 29 Mar 2005, Karl Czajkowski wrote:
On Mar 29, Donal K. Fellows loaded a tape reading:
Karl Czajkowski wrote:
Being able to mark some elements as mandatory and others as optional means that a consumer, for whatever reason, can filter out optional pieces and consider the remaining document as "equivalent" for the needs of the producer. This allows the consumer to eliminate extensions that it does not understand as well as parts it understands but which conflict with its own policies.
The problem is that there's no way for us to force such attributes on extension elements (I think) and we don't need it for any non-ext elements in JSDL since the spec has everything as "must understand" (though a consumer could reject the doc if it doesn't "support" the term in question).
We could do it via a wrapper... I am proposing this sort of mechanism in WS-Agreement as well:
1. treat elements in xsd:any extensibility slots as mandatory/critical
2. except, if wrapped in jsdl:noncriticalExtension which is an element w/ exactly one xsd:any##other in its body
karl
-- Karl Czajkowski karlcz@univa.com
--
---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------