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

["Tim Buss" <TBuss@xxxxxxxxxx>]

I have posted the content of this email to the ALF Wiki

http://wiki.eclipse.org/index.php/ALF/ALF_Schemas

Tim Buss
Serena Inc.

-----Original Message-----
From: Tim Buss 
Sent: Wednesday, August 16, 2006 6:01 PM
To: 'ALF Developer Mailing List'
Subject: Fw: ALF Event Schema simplification - Need to finalize by
August 31

In 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.