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
- From: "Vambenepe, William N" <vbp@hp.com>
- To: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>,"Steve Graham" <sggraham@us.ibm.com>
- Date: Fri, 19 Nov 2004 09:42:37 -0800
I don't understand why. Just because we define an event by
the QName of a "content" element it doesn't prevent us from assigning
events to topics when we define the events. What would make (1) impossible in
MOWS?
To provide a concrete example, consider a property foo in
capability bar. And two topics: t1 means "a property changed" and t2 means
"something related to capability bar happened". When foo changes, both people
who subscribed on t1 and t2 will get the a notification with the
"propertyChanged" content element. The question is simply whether this is
the same event sent over 2 topics (t1 and t2) or whether the event sent on topic
t1 is different from the event (with same content) sent over t2. It's mostly a
question of definition, not really a question of what you can
achieve.
Note that this discussion is independent from whether we
define a new <event> element for metadata or make use of WS-Topic to
cpature the pattern.
Regards,
William
Only 2) is possible in MOWS now
-- Igor
Sedukhin
..
(igor.sedukhin@ca.com)
-- (631)
342-4325
..
1 CA Plaza, Islandia, NY 11749
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
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]