On Dec 11, 2008, at 8:02 AM, Erik Rissanen wrote:
>
> If we focus back on the original issues for the 3.0 core we are
> working on:
>
> 1. Do we want to define a special mechanism for "Why" (and/or "What")?
> 2. If so, what is the concrete proposal for that?
> 3. Would it be mechanically different from obligations in any way?
> (And would it be a problem if it's identical. Well, I know you
> position on this Bill.;-))
Before I can answer #2 or #3 the TC must decide upon your proposal to
move Obligations to the Rule level :)
So, in the spirit of summarization I offer the following observations:
A. I believe that the justifications for the ObligationExpressions
proposal were the Boeing Use Cases and anecdotal observations that
others have run into similar issues.
B. These Use Cases were fairly specific: information as to WHY a
decision was made are needed
C. It was noted that V2 Obligations can partially solve this problem
D. The use of Obligations for this were met with a luke warm reception
(or is "kludge" tepid :D )
E. By making Obligations dynamic and adding them at the Rule level the
problem can be more fully solved
IF my summary is correct on this then I propose that we not extend
Obligations to the Rule level, make them dynamic and co-opt your
ObligationExpressions proposal to introduce (Cause|Advice)Expressions.
Under this scenario the machinery for this would be identical between
Obligations and Causes from the Policy level up, but would differ in
that only Causes would exist at the Rule level.
My fundamental reason for suggesting that we not extend Obligations
down is that they are poorly understood due to a lack of tangible
function. The original intent of handling asynchronous decision
actions has waned and what remains is a place to "put stuff that we
don't account for in the spec". I had hoped that a way to quantify
(and combine! :) such things would be found--which is why I spent a
number of weeks early in the V3 process thinking about how to approach
this--but it proved to be too difficult given a number of factors (not
the least of which are limitations in my skill set ;) Therefore I
would prefer that we do not extend something that is fundamentally
broken (yes, Polar, you did tell me so a few years ago :-p )
I am not excited about "duplicate" machinery, but if we have a chance
to address a real world problem in a precise way I think we should
explore it. If there is interest in this approach by others then I
would be happy to cut and paste the schema bits up, but I think what I
have outlined above is "concrete" enough for a general decision on
whether it is a viable option to pursue further.
thanks
b
