- From: Gilbert Pilz <gilbert.pilz@oracle.com>
- Date: Fri, 31 Jul 2009 13:41:27 -0700
- To: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <4A7356F7.2030503@oracle.com>
Reviewing the comment that created this issue [1], it seems that what Ben is looking for is a way to "tag" events with a string/label and to be able to create a simple, efficient filter based on these strings/labels. He expresses this requirement in terms of "topics", but I'm going to avoid that term because of all the semantic baggage that comes from all the different messaging/queuing systems that use it to mean similar but different things. So the first thing that occurs to me is that, if we are going to create a way to tag particular Event Types, we need a way to describe and advertise these tags. Similar to the XPATH filter, a Subscriber needs to know what the possible tags are and which tags apply to which Event Types if they are going to construct a tag filter that is at all useful. Naturally when I think of describing Event Types, I think of EventDescriptions. The following is an extended version of the "oceanevents.xml" file that I've been using as an example: <wse:EventDescriptions targetNamespace="http://www.example.org/oceanwatch/notifications" xmlns:wse="http://www.w3.org/2009/02/ws-evt" xmlns:ow="http://www.example.org/oceanwatch" xmlns:xs="http://www.w3.org/2001/XMLSchema"> . . . <wse:eventType name="WindReport" element="ow:WindReport" action="http://www.example.org/oceanwatch/2003/WindReport"> * <wse:eventTag>weather</wse:eventTag> <wse:eventTag>wind</wse:eventTag>* </wse:eventType> <wse:eventType name="RainReport" element="ow:RainReport" action="http://www.example.org/oceanwatch/2003/RainReport"/> * <wse:eventTag>weather</wse:eventTag> <wse:eventTag>rain</wse:eventTag>* </wse:eventType> . . . </wse:EventDescriptions> As you can see, the wse:eventType has been extended to include 0 or more "eventTag" elements. A few points: * The presence of "eventTag" elements in an EventDescriptions has no effect upon the corresponding Event Sink WSDL. * As will be shown later, the value of the "eventTag" elements appear as SOAP headers in the Notifications. * The use of EventDesciptions is simply one way of advertising tags and their relationship to Event Types. There may be others. * This proposal highlights one of the strengths of the EventDescriptions proposal; because we control the schema for EventDescriptions it is easier to modify/extend it to support features like event tagging. I assert that it would be more difficult to support similar functionality using the "linked-WSDLs" approach. - gp
Received on Friday, 31 July 2009 20:42:20 UTC