Hello Vicente,
XDAS defines a separate Outcome field, which is actually hierarchical as well, so you can have a generic failure or a failure because resources were exhausted, connection was down, etc. There's also an explicit "denied" which is different from "failed".
You're never supposed to send an XDAS event without defining the proper outcome, although I suppose you could default it to success.
Again, worth reviewing the XDAS if only to avoid doing the same work all over again. Here's a link:
http://www.opengroup.org/publications/catalog/p441.htm>>> On Thu, Mar 6, 2008 at 6:38 PM, in message
<
d88419760803061538r6390e183ra7a29b18d4d7ec1f@...>, Vicente Aceituno
<
vac@...> wrote:
> David,
>
> On 3/6/08, David Corlette <
DCorlette@...> wrote:
>>we are now treating an "event" as an interaction between three
> things: an initiator, an
>>originator, and a target. The initiator is the "thing(s)" that caused
> the event to occur, the
>>originator is the "thing(s)" that detected the event and reported it,
> and the target is the
>>"thing(s)" affected by the event.
>> What this leads to is four fundamental classes of data within an event
> structure, e.g. the
>>initiator, originator, target, and action.
> I agree with this approach. While in my lingo initiator, originator,
> target and action are object, subject, logger and request, my previous
> comments are perfectly aligned with your view.
>
> I would add to these general concepts that most recorded events are
> successful, this is the reason often the result of the action/request
> is not recorded. I think a standard should make this explicit. As I
> posted before, the action/request can result in success, failure or
> error.
>
> Best regards
>
> Vicente