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-c... 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