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

[Christopher Smith]

So I will agree that the MAY should be MUST (like stated in the other email
I just sent). 

As for the use of these, it's quite clear to me. One fault is used to
indicate to the client that the JSDL they are providing (and the extensions
to the JSDL that they use) are not implemented in the BES. The other is used
to say that I do indeed recognize that JSDL construct, but you have put
something in it that doesn't make sense to me. That is, to me, the principal
guiding the use of one over the other.

-- Chris



On 08/2/07 19:01, "Karl Czajkowski" <karlcz at univa.com> wrote:

> On Feb 08, Christopher Smith modulated:
> ...
>> The reason for the MAY is in the phrase "If the consuming system does not
>> provide the requested operating system....". Some systems may choose to
>> accept the JSDL as is, and might just have an activity whose resource
>> requirements can never be satisfied (unless an operating system of that type
>> is configured in the system and made available to the BES). This would be
>> the case for my BES implementation on top of LSF, which allows one to
>> specify resources that may never be satisfied.
>> 
> 
> Chris, I think you are trying to get at some awfully subtle
> distinctions here. Where do you draw the line between:
> 
>   1. XML unparseable (malformed)
>   2. XML unvalidatable (extension schema not known)
>   3. semantically inconsistent (schema allows meaningless expressions)
>   4. not supported by implementation
>   5. resources "never" available (not configured in cluster, etc.)
>   6. resources "temporarily" unavailable (due to load, etc.)
>   7. resources unavailable for given user role (due to policy, etc.)
>   ...
> 
> It would seem to me that you want to be careful in making sure faults
> are also interoperable if you are going to model them.  Can a
> programmatic client behavior take a meaningfully different fault
> response action based on the fault type here?  Or does this boil down
> to the fault indicating "the service did not like it" and there being
> some hints that a human might find useful during fault determination?
> 
> This leads me to wonder if there is any real information captured in
> these very similar fault messages.  If a system MAY report something
> as invalid when it might really be extensible value content not
> understood by the system, and if a system MAY accept something that is
> contradictory, what exactly is being communicated?
> 
> It would seem to me that you need a fault "lattice" where the most
> generic fault at the bottom can be generated and understood by any
> sensible implementation, while the more precise faults should have
> more stringent requirements on when they can be signalled.  I don't
> think you want to model subtle faults and then allow implementations
> to be liberal in what they generate here, as that would fail to encode
> real information for further processing decisions.
> 
> 
> karl