[ogsa-hpcp-wg] [OGSA-BES-WG] BES Last Call

[Andreas Savva]

Ok ... I'm really not trying to be difficult with this.

It's just that I find confusing a fault called
"InvalidRequestMessageFault" which can potentially mean both "it's a
legal value that I don't support" and "it's an illegal value".
Especially when there is another fault called "UnsupportedFeatureFault"
which means "an element was not supported".

Updating the definitions of these faults would help, but is it possible
to choose fault names that are sufficiently clear when viewed alone and
in combination?

Anyway, I think there's been sufficient traffic on this issue. Feel free
to dispose of it as you see fit and I'll probably give you a public
comment if I don't like the result. ;-)

Andreas

Christopher Smith wrote:
> Right ... as Karl says.
> 
> -- Chris
> 
> 
> On 12/2/07 23:04, "Karl Czajkowski" <karlcz at univa.com> wrote:
> 
>> On Feb 13, Andreas Savva modulated:
>> ...
>>> I asked the initial question because I could not understand why the case
>>> of giving an OS value from the JSDL-defined enumeration (well-defined
>>> presumably) would fall in the same category as that of specifying a
>>> fractional or negative value for CPUCount.
>>>
>> I think Chris sees this as an "out of range" error for the
>> implementation, without distinguishing necessarily between
>> "consistent, but not available in my resource manager", and
>> "inconsistent".  It is just a constraint that fails to match.
>>
>> In the general case, this distinction may be incomputable, though some
>> (optional) validation and analysis could weed out common
>> inconsistencies before handing the constraint to the solver. (Right,
>> Chris?)
>>
>> This is an area where I can see the value in being liberal in the
>> specification requirements to allow for a range of implementations.
>> The only issue is making sure the concept space is modeled such that a
>> less discerning implementation returns a more generic error and not a
>> detailed but mischaracterized description of what is going on... it is
>> that latter bit which pollutes the value of the detailed faults from
>> an interop point of view.
>>
>>
>> karl
> 

-- 
Andreas Savva
Fujitsu Laboratories Ltd