HPC Profile conf call Wed Nov 29 8am Pacific time: post-SC2006 discussion
Folks, First, I want to THANK EVERYBODY for their hard work leading up to and including the SC2006 interop demofest! I think we made tremendous progress and I want to continue the momentum inside the BES, JSDL, and HPC Profile working groups!!!! I propose that we have a conference call on Wed Nov 29 at 8am US Pacific time to discuss what we each learned while we implemented the HPC Profile, and where we as a group go from here. Please let me know if you can make this call (a few people said that Fridays were not good, so we're trying a different day -- but note: this is not necessarily proposed as a weekly call, this is just a "special" call to discuss things while SC is still in our minds). Rich Ciapala, Chris Smith and I tried to identify the unresolved issues that we either directly encountered or someone raised on the mailing list. We have certainly tried to capture everything but we probably missed a few things. Audience Topic HPCP WG Finalize security additions to profile BES WG Finalize faults for all operations BES WG Limit amount of data that can be returned from GetAttributesDocument HPCP WG Tools for which the schemas should work cleanly with JSDL WG RangeValue_Type element clarifications . If a single min value and a single max value are to be specified, should it be done with Boundary_Type's or a single Range_Type? . I assume Exact takes precedence over any specified Boundary_Type or Range_Type's since Exact is a MUST and the others are optional. BES WG Finalize Fault element's type for multiple response operations. We changed this from soap:Fault to xsd:anyType for the demo. HPCP WG Finalize list of dependent WS-I specs BES WG Use of QNAMEs in GetAttributesDocument response HPCP WG Data staging support BES WG Clarify operations semantics (i.e. TerminateActivity) So, please let me know if you can make this call on Wed Nov 29. Also, let's start email discussions on the appropriate mailing lists to attempt to resolve some of these (or at least prioritize these and identify new ones) before the call next Wednesday. Thanks again -- I think everything's coming together really well!!! -- Marty
On Nov 21, Marty Humphrey modulated:
RangeValue_Type element clarifications
-- If a single min value and a single max value are to be specified, should it be done with Boundary_Type’s or a single Range_Type?
They are semantically equivalent. The boundary parts are for defining semi-spaces, which cannot be expressed with the range pair.
-- I assume Exact takes precedence over any specified Boundary_Type or Range_Type’s since Exact is a MUST and the others are optional.
I do not think that is a correct assumption. I am not familiar with the "MUST" issue you are focusing on. What version of what document are you referencing here? The entire range-value element is meant to be expressing a disjunction of simple semi-space, exact, or interval constraints. So, if I expressed: OR [the combining logic of all range value elements] x > 0 [as a boundary sub-element] x = 4 [as an exact match sub-element] 5 < x < 7 [as a range sub-element] it would be semantically equivalent to just the first constraint x > 0. karl -- Karl Czajkowski karlcz@univa.com
I do not think that is a correct assumption. I am not familiar with the "MUST" issue you are focusing on. What version of what document are you referencing here?
I think Marty is referring to the HPC Profile document. It has (if I remember correctly) a statement that 'exact' must be implemented by all HPC Profile compliant JSDL implementations while the other range elements are recommended. I was unsure why the table had "JSDL-WG" against this issue since I think it is an issue for the HPC Profile and not for the JSDL spe. Andreas Karl Czajkowski wrote:
On Nov 21, Marty Humphrey modulated:
RangeValue_Type element clarifications
-- If a single min value and a single max value are to be specified, should it be done with Boundary_Type’s or a single Range_Type?
They are semantically equivalent. The boundary parts are for defining semi-spaces, which cannot be expressed with the range pair.
-- I assume Exact takes precedence over any specified Boundary_Type or Range_Type’s since Exact is a MUST and the others are optional.
I do not think that is a correct assumption. I am not familiar with the "MUST" issue you are focusing on. What version of what document are you referencing here?
The entire range-value element is meant to be expressing a disjunction of simple semi-space, exact, or interval constraints. So, if I expressed:
OR [the combining logic of all range value elements] x > 0 [as a boundary sub-element] x = 4 [as an exact match sub-element] 5 < x < 7 [as a range sub-element]
it would be semantically equivalent to just the first constraint x > 0.
karl
Marty Humphrey wrote:
RangeValue_Type element clarifications
· If a single min value and a single max value are to be specified, should it be done with Boundary_Type’s or a single Range_Type?
If you are specifying "at least X, but no upper bound" (or conversely "at most X, but no lower bound") then that's not done with a Range_Type. A Range_Type requires the use of explicit lower *and* upper bounds (we do not assume that any system handles infinities right, though that would have been a neater way to do it).
· I assume Exact takes precedence over any specified Boundary_Type or Range_Type’s since Exact is a MUST and the others are optional.
There is no "take precedence". The overall set of values matched by the RangeValue_Type is the set-union of the sets of values matched by the components of the RangeValue_Type. I would interpret the presence of a MUST only on the Exact as indicating that implementations may fault if the other kinds of component are used. I would categorically *not* take it as indicating any form of preference. If people want that, they'll have to add it through extensibility (or a wrapping WS-Agreement doc, or any number of other things). The JSDL interpretation is that anything in the specified RangeValue_Type is acceptable; if it wasn't, it would not have been specified. I'd actually expect real user requests to specify lower-closed ranges normally ("I want at least 10GB of memory, but more is cool too") and I'd expect system-driven refinements to replace that with Exacts ("You are going to get 12GB (because that's convenient for me to allocate, given the number of processors you're after)"). Donal (hoping this clarifies).
participants (4)
-
Andreas Savva -
Donal K. Fellows -
Karl Czajkowski -
Marty Humphrey