[jsdl-wg] JSDL Parameter Sweep extension

[geoff]

Hi Michel,

Thanks for getting in touch.

For the list, here is a (slightly modified) copy of the queries which 
prompted me to contact you earlier this year.

A) Specification queries:

A1) What timetable do you have for leading up to a final recommendation 
for the Parameter Sweep specification, and in which areas of the 
specification do you see the greatest potential for variation from the 
existing draft over time?

A2) The "Loop" element has "Exception" elements of type positiveInteger 
according to Appendix B. It also seems that the use of a positiveInteger 
type for attribute "step" is restricting functionality by preventing 
decrementing values. Is there a way of specifying a non-zero integer 
type in XML schema such as specifying a union of positiveInteger and 
negativeInteger?
Would it also be possible or practical to rename Loop to something like 
"LoopInteger"? I ask because I can imagine many situations where a 
looping process would be requested on Float, Date, values rather than 
integer values.

A3) The /sweepfunc:Value description (on page 10+11, section 3.2) 
appears to indicate that within the scope of the parent Values element 
all Value element values must have the same type. As the Value element 
values can be of xsd:anyType isn't it impossible to determine the 
precise type to validate for type consistency?
Related to this is the statement in 2.4 [Assignment] stating that 
"Implicit type-casting is not allowed". As a parameter element XPath can 
refer to any element (or part of) in the JSDL document the data type of 
the element/attribute being refered to may in many cases be 
indeterminable and I'd expect potentially impossible to accurately 
validate against corresponding function element values in many situations.
Note: Regarding Values, from what I could see on 
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-complexType 
the use of complexType has a default "mixed" attribute value of "false" 
so I don't think it's necessary to be defined in the schema.


B) Other queries - unfortunately I'm not an XML schema expert so would 
appreciate some guidance but if you're busy I'm sure I'll be able to 
find out from other sources:

B1) Do you anticipate permitting Sweep elements derived from different 
namespaces to be appearing in a JSDL Job Template: eg.

<jsdl:JobDefinition>
   ..
   <sweep:Sweep xmlns:sweep="http://schemas.ggf.org/vers.1/sweep>
     ..
   </sweep:Sweep>
   <sweep:Sweep xmlns:sweep="http://schemas.ggf.org/vers.2/sweep>
     ..
   </sweep:Sweep>
</jsdl:JobDefinition>

B2) Will any elements nested in a parent/root Sweep element (i.e. 
Assignment, Sweep) be able to use a different namespace to that of the 
parent/root Sweep element, e.g. Is the following valid?:

<jsdl:JobDefinition>
   ..
   <sweep:Sweep xmlns:sweep="http://schemas.ggf.org/vers.1/sweep>
     ..
     <sweep:Sweep xmlns:sweep="http://schemas.ggf.org/vers.2/sweep>
       ..
     </sweep:Sweep>
   </sweep:Sweep>
</jsdl:JobDefinition>

B3) As the Sweep schema is imported into the SweepFunc schema, does this 
imply that whenever a new Sweep schema (and corresponding namespace) is 
created then so must a new SweepFunc schema (and corresponding 
namespace) be defined so as to import the new Sweep?

B4) The use of nillable="false" in the "Values" "Value" element caused 
me some confusion as it seems that nillable implies that the element can 
still be empty, e.g.

   <value />, and <value></value>, are both valid,

It's just that nillable="false" prevents the use of;

   <value xsi:nil="true" />

Is this interpretation correct?

B5) How do you anticipate non-standard parameter sweep extensions being 
introduced to complement the standard extensions in the least disruptive 
way? Is there a best practice for this? I'm working on the assumption 
that it will take some time for requests for new functionality to feed 
through the OGF process from proposal to final recommendation so may 
need to generate non-standard extensions in the short term to meet the 
immediate needs of our users.


C) Some new stuff:

C1) Regarding the Loop functionality, having thought further I think it 
will be very beneficial to be able to loop on +ve and -ve float and 
integer values as part of a first specification release so as to avoid 
duplication in non-standard extensions. I'm going to discuss this issue 
with the potential users here soon to determine what precisely their 
parameter sweep requirements are, but from experience so far I've only 
seen looping on float values.

C2) I was also wondering if it needs to be specified that a parameter 
element value cannot reference another element within any sweep element 
scope e.g. the following would I think be considered valid as per the draft:

<sweep:Sweep>
   <sweep:Assignment>
     <sweep:Parameter>//jsdl-posix:Argument[2]</sweep:Parameter>
     <sweepfunc:Loop start="3" end="10" />
   </sweep:Assignment>
   <sweep:Sweep>
     <sweep:Assignment>
       <sweep:Parameter>//sweepfunc:Loop[0]/@end</sweep:Parameter>
       <sweepfunc:Loop start="1" end="2" />
     </sweep:Assignment>
   </sweep:Sweep>
</sweep:Sweep>

I can't imagine why someone would wish to do this, but is it within the 
specification remit to make it illegal to avoid dynamically modifying an 
element which represents a loop of some form?

gef

Michel Drescher wrote:
> Dear Neil, Geoff, Steve, Andre, Chris,
> 
> I would like to invite you guys to re-ignite the discussion and  
> standardisation efforts around parameter sweep definitions with JSDL.  
> There hasn't been much activity since months, and from comments I  
> received I think there is enough interest and effort now to get this  done.
> 
> As a starting point, please find attached the latest draft from June  
> last year (*ahem*...). I am sure there are loads of things that need  
> clarification and additional word-smithing, probably even some more  
> features (or change of existing ones) - no pun intended ;).
> 
> Please let's continue the discussion on the JSDL Mailing List (cc- ed); 
> you may have to subscribe to the Mailing List before you can  post to 
> it. To do so, please visit http://www.ogf.org/mailman/ listinfo/jsdl-wg 
> . You may also want to join the JSDL WG at OGF's  Gridforge site: 
> http://forge.ogf.org/sf/projects/jsdl-wg .
> 
> Cheers,
> Michel
> 
>