RE: [wsdm] Events metadata; Object now or comment after its in MUWS

[Steve Graham <sggraham@us.ibm.com>]

ok, I declare I am lost.  Serves
me right for sticking my nose late into a conversation that is well underway.
The term occasion is meaningless to
me, but if that is a WSDM term, so be it.  Does WEF not have some
sort of @occasion attr, to avoid having to define differrent occasions?

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

"Sedukhin, Igor S" <Igor.Sedukhin@ca.com>

11/19/2004 02:44 PM

To	Steve Graham/Raleigh/IBM@IBMUS
cc	Heather Kreger/Raleigh/IBM@IBMUS, "Vambenepe, William N" <vbp@hp.com>, <wsdm@lists.oasis-open.org>
Subject	RE: [wsdm] Events metadata; Object now or comment after its in MUWS

<ElementWithSomeInformation>
does not define a maningful event, it is just some information about something.
It has to be qualified as to what occasion it is emmited on in order to
become a meaningful event. So 1) define different elements for every occasion
or 2) define topics for every occasion
 
For example, say, I have an element
 
<RequestMessageInformation>
 
Now, I emit events on a) request
completed b) request failed
 
so I can declare
 
approach 1)  two
elements <RequestCompleted> and <RequestFailed> which contain
<RequestMessageInformation> to identify particular events
In answer to [No
requirement to define N variants of the "ElementWithSomeInformation".
 What am I missing?],
if I did not declare these two elements in this approach, then there is
no such thing as <RequestMessageInformation> event. It has to be
associated with a particular occasion to be a meaningful event.
 
or 
 
approach 2) two topics named RequestCompleted
and RequestFailed which both emit <RequestMessageInformation> which
also encodes the reasion sich as completed or failed, but in a way specific
to the request message.
 
The latter is now used in MOWS
and did not rase any concerns so far. Having miriads of elements declared
for every occasion seems unreasonable.

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749

 

---

From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: Friday, November 19, 2004 2:10 PM
To: Sedukhin, Igor S
Cc: Heather Kreger; Vambenepe, William N; wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Events metadata; Object now or comment after its
in MUWS


hmmm.... 
The mapping of event types to topics is potentially many to many.  
If you have different 'situations' that are detected, then model them with
different  element artifacts (ie different events) and then post each
to one or more topics.  However, you should allow for the case where
a given event can be posted to n different topics, no difference at all
in the event (type or instance), but simply different channels for different
audiences. 

>Would I then have to declare
<ElementWithSomeInformationForTheOccasionA> and <ElementWithSomeInformationForTheOccasionB>
event though the >contents is the same? This is what 1) would make me
do. 
I don't see why this is so.  The way I understood William's proposal
is that an event is defined by its content "GED".  An event
of that type could appear on Topic T1, T2... TN.  No requirement to
define N variants of the "ElementWithSomeInformation".  What
am I missing? 

sgg 

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++

"Sedukhin, Igor S" <Igor.Sedukhin@ca.com>

11/19/2004 01:19 PM

To	Steve Graham/Raleigh/IBM@IBMUS, "Vambenepe, William N" <vbp@hp.com>
cc	Heather Kreger/Raleigh/IBM@IBMUS, <wsdm@lists.oasis-open.org>
Subject	RE: [wsdm] Events metadata; Object now or comment after its in MUWS

Why is it not the best approach? 
  
If I have <ElementWithSomeInformation> and I emit <ManagementEvent>...<ElementWithSomeInformation>...
on different occasions then are you saying there is only one event identified
by the <ElementWithSomeInformation>? I would think that I'd declare
topics which will indicate which occasions the conglomerate of <ManagementEvent>
and <ElementWithSomeInformation> is emitted. And those topics would
actually identify events (occasions when the conglomerate is emitted).
  
Would I then have to declare <ElementWithSomeInformationForTheOccasionA>
and <ElementWithSomeInformationForTheOccasionB> event though the
contents is the same? This is what 1) would make me do.

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749

---

From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: Friday, November 19, 2004 1:08 PM
To: Vambenepe, William N
Cc: Heather Kreger; wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Events metadata; Object now or comment after its
in MUWS


3 topics, 3 different events does not sound like the best approach to me.
 Therefore I would prefer (1) 

++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++


"Vambenepe, William N" <vbp@hp.com> wrote on 11/19/2004
12:15:24 PM:

> They don't have to be. As long as we pick on definition and are clear
about it. 
>   
> 1) One definition is to say that an event is defined by a "content"
GED period. The
> fact that that event can be associated with multiple topics doesn't
change the fact
> that it's the same event. 
>   
> 2) Another definition is to say that an event is defined by the association
of a 
> topic and a "content" GED. That's the one I proposed below.
In this definition, if 
> the same content GED is associated with 3 different topics that makes
3 different events. 
>   
> Either is fine by me, but we need to clearly state what an event is.
>   
> In the spec right now I have version (2) but I can easily switch to
(1) if this is 
> what the group prefers. 
>   
> We need to decide on that first (what is an "event") before
we decide on what 
> metadata an event has. 
>   
> William 
> 
> From: Steve Graham [mailto:sggraham@us.ibm.com] 
> Sent: Friday, November 19, 2004 5:02 AM
> To: Vambenepe, William N
> Cc: Heather Kreger; wsdm@lists.oasis-open.org
> Subject: RE: [wsdm] Events metadata; Object now or comment after its
in MUWS

> 
> are events strictly associated with at most one topic?   
> 
> should the @topic be a list? 
>  <event topic="list of any URI" 
> ++++++++
> Steve Graham
> (919)254-0615 (T/L 444)
> STSM, On Demand Architecture
> Member, IBM Academy of Technology
> <Soli Deo Gloria/>
> ++++++++
> 
> 

> 
> "Vambenepe, William N" <vbp@hp.com> 
> 11/18/2004 06:44 PM 
> 
> To 
> 
> Heather Kreger/Raleigh/IBM@IBMUS, <wsdm@lists.oasis-open.org>
> 
> cc 
> 
> Steve Graham/Raleigh/IBM@IBMUS 
> 
> Subject 
> 
> RE: [wsdm] Events metadata; Object now or comment after its in MUWS
> 
> 
> 
> 
> Heather, 
>   
> I am trying to picture a metadata document with a bunch of these <event>
elements 
> in it. How do I tell what event each of these elements relate to?
Which begs the 
> larger question: what is an event. 
>   
> In our spec, whenever we define an event we do so by selecting a topic
and a GED to
> represent the content of this event. So it seems to me that our definition
of an 
> event is something uniquely identified by a URI (topic), a GED (content)
and a 
> description of the semantics in human-readable (at least geek-readable)
form. 
>   
> Based on this, I think the event metadata element you propose would
look better like this: 
>   
>   <event topic="any URI" content="xs:QName">
>    <situationCategory> ws-muws:category</situationCategory>
? 
>    <severity>xs:short<severity> ? 
>    {any} * 
>  </event> 
> With @topic and @content being required so I know what event this
metadata is about. 
>   
> Also, if we go with this proposal can you show us what the topic document
would 
> look like? Like would be in topic/@messageType? 
>   
> William 
>   
> 
> From: Heather Kreger [mailto:kreger@us.ibm.com] 
> Sent: Thursday, November 18, 2004 2:42 PM
> To: wsdm@lists.oasis-open.org
> Cc: Steve Graham
> Subject: [wsdm] Events metadata; Object now or comment after its in
MUWS
> 
> 
> I had an outstanding action item to look into using topics and message
patterns to 
> convey information that managers would need to know about expected
events ahead of 
> time.  Here are our conclusions: 
> 
> While it is possible to advertise the values of this information in
messagePattern 
> of a topic, the XPath would be very complicated and Igor's complaints
about the 
> amount of processing and reverse engineering to infer the category
and severity 
> would be valid.  We are really trying to advertise information
ABOUT the event, not
> a broad shape or signature of the message. Instead it seems much cleaner
to 
> advertise with the resource, who is already advertising events to
be issued,  some 
> of the important values to be expected by the manager in the event.
This enables 
> managers to find all events that will be emitted in a particular situationCategry
> or severity.  It also makes it very clear what additional elements
are being added 
> into the WEF's open content.  I think this ties to the topics
work today very 
> neatly without makeing very complex messagePatterns. 
> 
> Therefore, I'd like to propose the following metadata for events emitted
from 
> manageable resources: 
> 
> Events are emitted from manageable resources in the form of WSDM Event
Format 
> [WSDMEventFormat].  The event metadata element describes the
types of events that 
> can be emitted and hints on how the WSDM Event Format will be constructed.
  
> 
> The form of the event element is extended as shown here.   
> 
>  <xs:element name=’event’> 
>    <xs:complexType> 
>      <xs:sequence> 
>        <xs:element name=’situationCategory’
type=’ws-muws:category’ 
>                    minOccurs=’0’/>
>        <xs:element name=’severity’ type=’xs:short’
>                    minOccurs=’0’/>
>        <xs:element name=’messagePattern’
type=’xs:QName’ 
>                    minOccurs=’0’/>
>        <xs:any namespace=’##other’ 
>                minOccurs=’0’
maxOccurs=’unbounded’/> 
>      </xs:sequence> 
>    </xs:complexType> 
>  </xs:element> 
> 
> 
> 
>  <event> 
>    <situationCategory> ws-muws:category</situationCategory>
? 
>    <severity>xs:short<severity> ? 
>    <messagePattern>xs:QName</messagePattern>
? 
>    {any} * 
>  </event> 
> 
> 
> 
> /mrp:event/situationCategory 
> The value that will appear in the situationCategory element of the
situation 
> element of WSDM Event Format events of this type, with potential values
as defined 
> in [WSDMBaseEvent].   
> 
> /mrp:event/severity 
> The value that will appear in the severity element of the WSDM Event
Format events 
> of this type, with potential values as defined in [WSDMBaseEvent].
  
> 
> /mrp:event/messagePattern 
> The value that will be the QName of the schema element expected in
the open content
> model for the WSDM base event. This value will also appear in the
messagePattern 
> for the Topic for the event. 
> 
> This is an open content model, so additional, domain specific, relevant
information
> in the events could be advertised. 
> 
> Given the timeframe, 
> I propose that if there are not objections on Friday by COB EST, that
this be added
> to MUWS. Of course, you can still comment during the comment period.
> 
> Heather Kreger
> STSM, Web Services Lead Architect for SWG Emerging Technologies
> Author of "Java and JMX: Building Manageable Systems"
> kreger@us.ibm.com
> 919-543-3211 (t/l 441)  cell:919-496-9572