[alf-dev] Fw: ALF Event Schema simplification - Need to finalize by Augu

["Tim Buss" <TBuss@xxxxxxxxxx>]

 <<ALFBasicEvent.xsd>> In <<ALFBasicEvent_001.xsd>> case you are not a
newsgroup regular, here is a copy of a post just made to the ALF
newsgroup.
You feedback is appreciated.  Please reply to this email of post to the
Newsgroup as is your preference

Thanks,
Tim buss   


"Tim Buss" <t b u s s @ S e r e n a . c o m> wrote in message
news:<ec0esf$nqp$1@xxxxxxxxxxxxxxxxx>...
> We have been reviewing the ALF Event Schema and our recommendation is
that
> if should be flattened and simplified.  Here the details of our
suggestions
> and reasoning so far.  A copy of the original (ALFBasicEvent.xsd) and
> proposed (ALFBasicEvent_001.xsd) schemas are attached.  The proposed
schema
> is just for illustration and should not be considered final.  Please
respond
> with any comments you may have and any other suggestions about way to
> streamline the ALF event Schema.  We would like to finalize the ALF
Event
> Schema by the end of this month - August 31 2006.
> 
> 
> 
>   1.. Eliminate a nesting level between BasicEventType and Event Data
such
> that. This serves no particular purpose except to separate it from the
> Context Array which is not returned on an ACK.  If we eliminate the
Context
> Array as I suggest below then this distinction is no longer required
> 
> 
>   2.. Eliminate the Object Array in favor of a single ObjectType in
the
> contained in the BasicEventType.  It seems to me that is very rare
that we
> will encounter a situation where a tool cannot provide a single
identity to
> use to call back for additional information.  While the array and
related
> "relationship" attribute may be potentially powerful it would seem
better
> relegated to a potential common vocabulary type for vocabulary or tool
> specific event details.  The only potential issue is that removing the
array
> from the basic event also removes it from the consideration as part of
an
> ALF event manager dispatch rule.  Currently we only use the first
object in
> the array.  This seems a reasonable price to pay  The array seems
somewhat
> complex for that purpose due to its rather arbitrary nature and, if we
find
> we are really missing it later we have the option of  extending the
Basic
> Event to include an array of this nature in addition to the primary
object.
> 
> 
>   3.. Eliminate the Context Array and merge the current user details
into
> the BasicEventType.  The context array does not seem that useful to
me.  It
> just makes the current context harder to discern.  Further, it does
not seem
> to be desirable from a security standpoint to be passing around arrays
of
> credentials.  I don't see any particular programmatic use of this
feature
> and a simple log or a relationship store would be a better method of
tracing
> contexts after the event.  Even if it is of some practical use, that
use
> relies on the support to tools to return the context in full in an
event.
> This seems unlikely except by the most avid of ALF participating tools
> rendering it useless in the foreseeable future.
> 
> 
>   4.. Eliminate "InitiatingFlow" and the "nesting" attribute as an
aspect of
> the Context.  This does not provide much useful information and again
relies
> on all participants to behave the ALF way in order for the nesting
counter
> to accurate.  Instead provide some preceding IDs ( see below)  and
rely on
> logging.  I am unclear whether it would be useful to know if the event
comes
> from a user interaction or a service flow.  It would seem to me likely
that
> that this can be inferred from the event type and event product
information
> and not explicit flag is required.  I am unclear what you would do
with it
> in any case. Thus I would just eliminate it.
> 
> 
>   5.. Add  "PrecedingEvent" and "PrecedingServiceFlow" to the Basic
Event
> Type as nillable elements. If the event is generated in the directly
by a
> service flow then the ServiceFlow will fill these, identifying itself
and
> the event that initiated it.  Optionally an ALF compliant service may
take
> this data and return it in any event it generates.  The Source
elements can
> be used to distinguish the cases.
> 
> 
>   6.. Add a ALFEventNoACK element and associated Type.  Async Service
flows
> have this type.  Unfortunately the Event Manager currently dispatches
using
> ALFEventACK which is incorrect and confusing.
> 
> 
>   7.. Eliminate the use of the "mixed" attribute.  I believed the used
of
> the attribute "mixed" is incorrect.  This attribute means that and
element
> can contain both content text and other elements.  I don't think that
is the
> intent.  Its use here appears to be associated with the use of an
attribute
> which is incorrect.
> 
> 
> 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Attachment: ALFBasicEvent.xsd
Description: Binary data

Attachment: ALFBasicEvent_001.xsd
Description: Binary data