[jsdl-wg] GGF 13 notes and further discussion

[Christopher Smith]

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 at 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 at univa.com
>> 
>> 
> 
> --
> 
>         ---------------------------------------------------- |epcc| -
>         Ali Anjomshoaa
>         EPCC, University of Edinburgh
>         James Clerk Maxwell Building
>         Mayfield Road                   E-mail: ali at epcc.ed.ac.uk
>         Edinburgh EH9 3JZ               Phone:  + 44 (0) 131 651 3388
>         United Kingdom                  Fax:    + 44 (0) 131 650 6555
>         -------------------------------------------------------------
>