OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]