This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/go/projects.ggf-editor/discussion.rec_jsdl_spec_v1_0.alternative_resource_requirement at Sun, 06 Nov 2022 09:02:43 GMT SourceForge : Post

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Project: Editor     Discussion > REC: JSDL Spec v1.0 > Alternative resource requirements > List of Posts
Forum Topic - Alternative resource requirements: (4 Items)
View:  as 
 
 
Alternative resource requirements
I have just noticed that cardinality of the Resource element was changed from unbounded to 1 and that profiles were also
 removed. Therefore a definition of alternative resource requirements is not possible. Is it right?
I mean definition of, for instance, requirements for two 2GHz CPUs OR four 1GHz CPUs.
I think this is rather important functionality and it does not make the schema too complex so I'm supprised that it 
disappeared.
Thanks,
Ariel
Re: Alternative resource requirements
Thanks for the answer.
I agree that Profiles were quite complex, however, <Resource../>* element is rather simple and IMHO it does allow 
defining alternatives. I agree that all requirements that belong to the Resource element must be satisfied but if we 
define multiple Resource elements they should represent alternative requirements. Otherwise this is not reasonable 
because a conjunction of conjunctions is just a conjunction of all elements, e.g.  (x and y) and (z and u) = x and y and
 z and u.
Regards
Ariel
Re: Alternative resource requirements
<Resource.../>* was meant to allow for heterogeneous resource descriptions. For example, 2 intel servers and 1 sparc 
machine. As such the conjunction rule was (and is) valid.

Actually we had long discussions about this 'implicit or' rule when there were multiple elements of the same type at the
 same level. It just gets too complex when there are more than 1 implicit rule. (For me anyway.)

Andreas
Re: Alternative resource requirements
Ranges allow specifying alternatives to some extent in JSDL 1.0. (But I think not the exact example you raise.) 

Expressing alternatives is important but it has consistently proven too complex an issue to settle to everyone's 
satisfaction. The issues had more to do with semantics rather than keeping the schema simple.  Profiles were introduced 
as a way to define alternatives but were considered too complex (in particular their substitution rules) during the 
review at GGF13 (Korea) and were removed from the specification.

The later change from <Resource../>* to <Resources../>? does not affect things because the ability to define multiple 
Resource elements did not allow for alternatives. (All Resource elements had to be satisfied.)

Finally, other specifications, such as WS-Agreement, have defined operators to express alternatives over XML elements. 
It is possible to combine JSDL with such specs (without necessarily taking on all the extra framework they define) in 
order to specify alternatives. So it is not clear to me the advantage of duplicating the definition of such operators in
 JSDL, at least not in version 1.0.

Thanks for your comments.
Andreas

 
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/go/projects.ggf-editor/discussion.rec_jsdl_spec_v1_0.alternative_resource_requirement at Sun, 06 Nov 2022 09:02:43 GMT