- From: Doug Davis via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 28 Jul 2009 23:13:03 +0000
- To: public-ws-resource-access-notifications@w3.org
Update of /w3ccvs/WWW/2002/ws/ra/edcopies
In directory hutz:/tmp/cvs-serv15987
Modified Files:
wseventing.html wseventing.xml
Log Message:
6692
Index: wseventing.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wseventing.xml,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -d -r1.55 -r1.56
--- wseventing.xml 28 Jul 2009 17:53:42 -0000 1.55
+++ wseventing.xml 28 Jul 2009 23:13:01 -0000 1.56
@@ -39,7 +39,6 @@
</loc>
</prevlocs>
-
<authlist>
<author>
<name>Doug Davis</name>
@@ -134,10 +133,7 @@
There are many mechanisms by which event sources may deliver
events to event sinks. This specification provides an extensible
way for subscribers to identify the delivery mechanism they
- prefer. While asynchronous, pushed delivery is defined here, the
- intent is that there should be no limitation or restriction on
- the delivery mechanisms capable of being supported by this
- specification.
+ prefer.
</p>
<div2 id="reqs">
@@ -211,35 +207,27 @@
</ulist>
</div2>
- <div2 id="DeliveryModes">
- <head>Delivery Modes</head>
+ <div2 id="Delivery">
+ <head>Delivery</head>
<p>
- While the general pattern of asynchronous, event-based
- messages is extremely common, different applications often
- require different notification delivery mechanisms. For
- instance, in some cases a simple asynchronous message is optimal,
- while other situations may work better if the event consumer can
- poll for notification in order to control the flow and timing
- of message arrival. Some consumers will require notifications to
- be wrapped in a standard "event" SOAP envelope, while others will
- prefer messages to be delivered unwrapped. Some consumers may
- require notifications to be delivered reliably, while others may
- be willing to accept best-effort event delivery.
+ This specification defines a method for transmitting notifications from
+ the event source to the event sink through the use of the wse:NotifyTo
+ element. Other
+ methods or combination of methods may be defined through the use
+ of delivery extensions.
</p>
+ </div2>
+
+ <div2 id="NotificationFormats">
+ <head>Notification Formats</head>
<p>
- In order to support this broad variety of event delivery
- requirements, this specification introduces an abstraction called
- a Delivery Mode and an abstraction called Delivery Format.
- These concepts are used as an extension points, so
- that event sources and event consumers may freely create new
- delivery mechanisms that are tailored to their specific
- requirements. This specification provides a minimal amount of
- support for delivery mode and format negotiation by allowing an event
- source to provide a list of supported delivery modes and formats
- in response to a subscription request specifying a delivery mode
- or format it does not support.
+ This specification specifies two delivery formats: wrapped
+ and unwrapped. Use of wrapped format indicates
+ that notification messages should be contained in a wrapper
+ element. Use of unwrapped format indicates that notification messages
+ are not wrapped.
</p>
<p>
@@ -248,19 +236,6 @@
of what type of formatting might occur, the same Filter dialect/expression
can be used to subset the event stream.
</p>
-
- <p>
- This specification defines a single delivery mode, Push Mode,
- which is simple asynchronous messaging.
- </p>
-
- <p>
- This specification specifies two delivery formats: wrapped
- and unwrapped. Use of wrapped format indicates
- that notification messages should be contained in a wrapper
- element. Use of unwrapped format indicates that notification messages
- are not wrapped.
- </p>
</div2>
<div2 id="SubMgr">
@@ -348,9 +323,9 @@
While lines (13-15) indicate where a reply should be sent,
lines (20-29) indicate where and how notifications should be
delivered; there is no requirement that these match. The absence
- of a Mode attribute on line (20) indicates that notifications
- should be delivered using Push mode; that is, they should be
- asynchronously sent as SOAP messages to the endpoint described in
+ of any extensions to the wse:Delivery or wse:NotifyTo elements
+ indicates that notifications
+ should be sent as SOAP messages to the endpoint described in
lines (21-28). Note that lines (25-27) illustrate a typical
pattern where the event sink lists a reference parameter (line 26)
that identifies the subscription and will be included in each
@@ -678,16 +653,6 @@
<glist>
<gitem>
- <label> Delivery Mode </label>
- <def>
- <p>
- The mechanism by which notifications are delivered from
- the source to the sink.
- </p>
- </def>
- </gitem>
-
- <gitem>
<label> Event Source </label>
<def>
<p>
@@ -717,16 +682,6 @@
</gitem>
<gitem>
- <label> Push Mode </label>
- <def>
- <p>
- A delivery mechanism where the source sends notifications
- to the sink as unsolicited, asynchronous SOAP messages.
- </p>
- </def>
- </gitem>
-
- <gitem>
<label> Subscriber </label>
<def>
<p>
@@ -823,7 +778,7 @@
<kw>[Body]</kw>
<wse:Subscribe ...>
<wse:EndTo> <emph>endpoint-reference</emph> </wse:EndTo> ?
- <wse:Delivery Mode="<emph>xs:anyURI</emph>"? ...> <emph>xs:any</emph>* </wse:Delivery>
+ <wse:Delivery ...> <emph>xs:any</emph>* </wse:Delivery>
<wse:Format Name="<emph>xs:anyURI</emph>"? > <emph>xs:any</emph>* </wse:Format> ?
<wse:Expires> (<emph>xs:dateTime</emph> | <emph>xs:duration</emph>) </wse:Expires> ?
<wse:Filter Dialect="<emph>xs:anyURI</emph>"? ...> <emph>xs:any</emph>* </wse:Filter> ?
@@ -861,46 +816,22 @@
<label> <kw>[Body]</kw>/wse:Subscribe/wse:Delivery </label>
<def>
<p>
- A delivery destination for notification messages, using
- some delivery mode. See <specref ref="DeliveryModes"/>
- for details.
- </p>
- </def>
- </gitem>
-
- <gitem>
- <label> <kw>[Body]</kw>/wse:Subscribe/wse:Delivery/@Mode </label>
- <def>
- <p>
- The delivery mode to be used for notification messages
- sent in relation to this subscription. Implied value is
- "http://www.w3.org/2009/02/ws-evt/DeliveryModes/Push",
- which indicates that Push Mode delivery should be used. See
- <specref ref="DeliveryModes"/> for
- details.
- </p>
-
- <p>
- If the event source does not support the requested
- delivery mode, the request MUST fail, and the event source
- MUST generate a wse:DeliveryModeRequestedUnavailable fault
- indicating that the requested delivery mode is not
- supported.
+ This element contains the information necessary to convey
+ notification messages from the event source to the event sink in
+ a manner required by the subscriber. This element MUST contain
+ at least one child element.
</p>
</def>
</gitem>
<gitem>
- <label>
- <kw>[Body]</kw>/wse:Subscribe/wse:Delivery/@Mode="http://www.w3.org/2009/02/ws-evt/DeliveryModes/Push"
- </label>
+ <label> <kw>[Body]</kw>/wse:Subscribe/wse:Delivery/wse:NotifyTo </label>
<def>
<p>
- Value of <kw>[Body]</kw>/wse:Subscribe/wse:Delivery MUST contain at
- least
- the single element, wse:NotifyTo, that contains the endpoint reference
- to which notification messages should be sent. The value of this
- element is not constrained for other delivery modes.
+ This specification defines one OPTIONAL element, wse:NotifyTo, to
+ be used as a child of the wse:Delivery element. When present this
+ element indicates that notifications MUST be sent to the
+ EndpointReference identified by this element.
</p>
</def>
</gitem>
@@ -914,7 +845,7 @@
relation to this subscription. Implied value is
"http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Unwrap", which
indicates that unwraped delivery should be used. See
- Section <specref ref="DeliveryModes"/> for details.
+ Section <specref ref="NotificationFormats"/> for details.
</p>
<p>
@@ -2093,46 +2024,6 @@
</div2>
- <div2 id="ModeUnavailable">
- <head>DeliveryModeRequestedUnavailable</head>
-
- <p>
- This fault is sent when a Subscribe request specifies a
- delivery mode that is not supported by the event source.
- Optionally, this fault may contain a list of supported delivery
- mode URIs in the Detail property.
- </p>
-
- <table border="1">
- <tbody>
- <tr>
- <td><kw>[Code]</kw></td>
- <td>s12:Sender</td>
- </tr>
-
- <tr>
- <td><kw>[Subcode]</kw></td>
- <td>wse:DeliveryModeRequestedUnavailable</td>
- </tr>
-
- <tr>
- <td><kw>[Reason]</kw></td>
- <td>The requested delivery mode is not supported.</td>
- </tr>
-
- <tr>
- <td><kw>[Detail]</kw></td>
- <td>
- <wse:SupportedDeliveryMode> +
- <phrase/>
- <emph>Optional; one per delivery mode supported by the
- receiver</emph>
- </td>
- </tr>
- </tbody>
- </table>
- </div2>
-
<div2 id="InvalidExpirationTime">
<head>InvalidExpirationTime</head>
@@ -2857,7 +2748,7 @@
information to be retrieved. The WSDL will contain annotations
that identify a service as an event source and that identify
those messages that describe notification messages. The policy
- will specify the delivery modes and filter types supported by the
+ will specify the delivery extensions and filter types supported by the
event source.
</p>
@@ -3027,8 +2918,6 @@
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
- <xs:attribute name="Mode" type="xs:anyURI" use="optional"
- default="http://http://www.w3.org/2009/02/ws-evt/DeliveryModes/Push" />
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>
@@ -3111,9 +3000,6 @@
<!-- Used in a fault if there's an unsupported dialect -->
<xs:element name="SupportedDialect" type="xs:anyURI" />
- <!-- Used in a fault if there's an unsupported delivery mode -->
- <xs:element name="SupportedDeliveryMode" type="xs:anyURI" />
-
<!-- Used in a fault if there's an unsupported format name -->
<xs:element name="SupportedDeliveryFormat" type="xs:anyURI" />
@@ -3686,6 +3572,13 @@
<loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6980">6980</loc>
</td>
</tr>
+ <tr>
+ <td> 2009/07/28 </td>
+ <td> DD </td>
+ <td> Added resolution of issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692">6692</loc>
+ </td>
+ </tr>
</tbody>
</table>
</div1>
Index: wseventing.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wseventing.html,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -d -r1.64 -r1.65
--- wseventing.html 28 Jul 2009 17:53:42 -0000 1.64
+++ wseventing.html 28 Jul 2009 23:13:01 -0000 1.65
@@ -42,9 +42,10 @@
<h2><a name="contents" id="contents"/>Table of Contents</h2><p class="toc">1 <a href="#composable">Composable Architecture</a><br/>
2 <a href="#intro">Introduction</a><br/>
2.1 <a href="#reqs">Requirements</a><br/>
- 2.2 <a href="#DeliveryModes">Delivery Modes</a><br/>
- 2.3 <a href="#SubMgr">Subscription Managers</a><br/>
- 2.4 <a href="#example">Example</a><br/>
+ 2.2 <a href="#Delivery">Delivery</a><br/>
+ 2.3 <a href="#NotificationFormats">Notification Formats</a><br/>
+ 2.4 <a href="#SubMgr">Subscription Managers</a><br/>
+ 2.5 <a href="#example">Example</a><br/>
3 <a href="#notterms">Notations and Terminology</a><br/>
3.1 <a href="#conventions">Notational Conventions</a><br/>
3.2 <a href="#extensions">Considerations on the Use of Extensibility Points</a><br/>
@@ -60,17 +61,16 @@
5 <a href="#Notifications">Notifications</a><br/>
6 <a href="#Faults">Faults</a><br/>
6.1 <a href="#FaultDetailRetryElement">Fault Detail RetryAfter Element</a><br/>
- 6.2 <a href="#ModeUnavailable">DeliveryModeRequestedUnavailable</a><br/>
- 6.3 <a href="#InvalidExpirationTime">InvalidExpirationTime</a><br/>
- 6.4 <a href="#UnsupportedExpirationType">UnsupportedExpirationType</a><br/>
- 6.5 <a href="#FilteringNotSupported">FilteringNotSupported</a><br/>
- 6.6 <a href="#FilteringRequestedUnavailable">FilteringRequestedUnavailable</a><br/>
- 6.7 <a href="#EventSourceUnableToProcess">EventSourceUnableToProcess</a><br/>
- 6.8 <a href="#UnableToRenew">UnableToRenew</a><br/>
- 6.9 <a href="#InvalidMessage">InvalidMessage</a><br/>
- 6.10 <a href="#DeliveryFormatRequestedUnavailable">DeliveryFormatRequestUnavailable</a><br/>
- 6.11 <a href="#EmptyFilter">EmptyFilter</a><br/>
- 6.12 <a href="#UnusableEPR">UnusableEPR</a><br/>
+ 6.2 <a href="#InvalidExpirationTime">InvalidExpirationTime</a><br/>
+ 6.3 <a href="#UnsupportedExpirationType">UnsupportedExpirationType</a><br/>
+ 6.4 <a href="#FilteringNotSupported">FilteringNotSupported</a><br/>
+ 6.5 <a href="#FilteringRequestedUnavailable">FilteringRequestedUnavailable</a><br/>
+ 6.6 <a href="#EventSourceUnableToProcess">EventSourceUnableToProcess</a><br/>
+ 6.7 <a href="#UnableToRenew">UnableToRenew</a><br/>
+ 6.8 <a href="#InvalidMessage">InvalidMessage</a><br/>
+ 6.9 <a href="#DeliveryFormatRequestedUnavailable">DeliveryFormatRequestUnavailable</a><br/>
+ 6.10 <a href="#EmptyFilter">EmptyFilter</a><br/>
+ 6.11 <a href="#UnusableEPR">UnusableEPR</a><br/>
7 <a href="#Security">Security Considerations</a><br/>
7.1 <a href="#MessageSecurity">Message Security</a><br/>
7.2 <a href="#AccessControl">Access Control</a><br/>
@@ -117,10 +117,7 @@
There are many mechanisms by which event sources may deliver
events to event sinks. This specification provides an extensible
way for subscribers to identify the delivery mechanism they
- prefer. While asynchronous, pushed delivery is defined here, the
- intent is that there should be no limitation or restriction on
- the delivery mechanisms capable of being supported by this
- specification.
+ prefer.
</p><div class="div2">
<h3><a name="reqs" id="reqs"/>2.1 Requirements</h3><p>
This specification intends to meet the following requirements:
@@ -150,46 +147,26 @@
limited to) both SOAP 1.1 <a href="#SOAP11">[SOAP 1.1]</a>
and SOAP 1.2 <a href="#SOAP121">[SOAP 1.2]</a> Envelopes.
</p></li></ul></div><div class="div2">
-<h3><a name="DeliveryModes" id="DeliveryModes"/>2.2 Delivery Modes</h3><p>
- While the general pattern of asynchronous, event-based
- messages is extremely common, different applications often
- require different notification delivery mechanisms. For
- instance, in some cases a simple asynchronous message is optimal,
- while other situations may work better if the event consumer can
- poll for notification in order to control the flow and timing
- of message arrival. Some consumers will require notifications to
- be wrapped in a standard "event" SOAP envelope, while others will
- prefer messages to be delivered unwrapped. Some consumers may
- require notifications to be delivered reliably, while others may
- be willing to accept best-effort event delivery.
- </p><p>
- In order to support this broad variety of event delivery
- requirements, this specification introduces an abstraction called
- a Delivery Mode and an abstraction called Delivery Format.
- These concepts are used as an extension points, so
- that event sources and event consumers may freely create new
- delivery mechanisms that are tailored to their specific
- requirements. This specification provides a minimal amount of
- support for delivery mode and format negotiation by allowing an event
- source to provide a list of supported delivery modes and formats
- in response to a subscription request specifying a delivery mode
- or format it does not support.
- </p><p>
- When the Delivery Format feature is engaged the formatting of the
- outgoing events occurs after any filtering. This ensures that regardless
- of what type of formatting might occur, the same Filter dialect/expression
- can be used to subset the event stream.
- </p><p>
- This specification defines a single delivery mode, Push Mode,
- which is simple asynchronous messaging.
- </p><p>
+<h3><a name="Delivery" id="Delivery"/>2.2 Delivery</h3><p>
+ This specification defines a method for transmitting notifications from
+ the event source to the event sink through the use of the wse:NotifyTo
+ element. Other
+ methods or combination of methods may be defined through the use
+ of delivery extensions.
+ </p></div><div class="div2">
+<h3><a name="NotificationFormats" id="NotificationFormats"/>2.3 Notification Formats</h3><p>
This specification specifies two delivery formats: wrapped
and unwrapped. Use of wrapped format indicates
that notification messages should be contained in a wrapper
element. Use of unwrapped format indicates that notification messages
are not wrapped.
+ </p><p>
+ When the Delivery Format feature is engaged the formatting of the
+ outgoing events occurs after any filtering. This ensures that regardless
+ of what type of formatting might occur, the same Filter dialect/expression
+ can be used to subset the event stream.
</p></div><div class="div2">
-<h3><a name="SubMgr" id="SubMgr"/>2.3 Subscription Managers</h3><p>
+<h3><a name="SubMgr" id="SubMgr"/>2.4 Subscription Managers</h3><p>
In some scenarios the event source itself manages the
subscriptions it has created. In other scenarios, for example a
geographically distributed publish-and-subscribe system, it may
@@ -211,7 +188,7 @@
whether it is the event source itself or some separate Web
service.
</p></div><div class="div2">
-<h3><a name="example" id="example"/>2.4 Example</h3><p><a href="#Table1">Example 2-1</a> lists a hypothetical request to create a
+<h3><a name="example" id="example"/>2.5 Example</h3><p><a href="#Table1">Example 2-1</a> lists a hypothetical request to create a
subscription for storm warnings.
</p><div class="exampleOuter">
<div class="exampleHeader"><a name="Table1" id="Table1"/>Example 2-1: Hypothetical request to create a subscription</div><div class="exampleInner"><pre>(01) <s12:Envelope
@@ -254,9 +231,9 @@
While lines (13-15) indicate where a reply should be sent,
lines (20-29) indicate where and how notifications should be
delivered; there is no requirement that these match. The absence
- of a Mode attribute on line (20) indicates that notifications
- should be delivered using Push mode; that is, they should be
- asynchronously sent as SOAP messages to the endpoint described in
+ of any extensions to the wse:Delivery or wse:NotifyTo elements
+ indicates that notifications
+ should be sent as SOAP messages to the endpoint described in
lines (21-28). Note that lines (25-27) illustrate a typical
pattern where the event sink lists a reference parameter (line 26)
that identifies the subscription and will be included in each
@@ -399,10 +376,7 @@
http://www.w3.org/2005/07/13-nsuri
</a>.
</p></div><div class="div2">
-<h3><a name="terms" id="terms"/>3.4 Terminology</h3><dl><dt class="label"> Delivery Mode </dt><dd><p>
- The mechanism by which notifications are delivered from
- the source to the sink.
- </p></dd><dt class="label"> Event Source </dt><dd><p>
+<h3><a name="terms" id="terms"/>3.4 Terminology</h3><dl><dt class="label"> Event Source </dt><dd><p>
A Web service that sends notifications and accepts
requests to create subscriptions.
</p></dd><dt class="label"> Event Sink </dt><dd><p>
@@ -410,9 +384,6 @@
</p></dd><dt class="label"> Notification </dt><dd><p>
A one-way message sent to indicate that an event, or events,
have occurred.
- </p></dd><dt class="label"> Push Mode </dt><dd><p>
- A delivery mechanism where the source sends notifications
- to the sink as unsolicited, asynchronous SOAP messages.
</p></dd><dt class="label"> Subscriber </dt><dd><p>
A Web service that sends requests to create, renew, and/or
delete subscriptions.
@@ -470,7 +441,7 @@
<b>[Body]</b>
<wse:Subscribe ...>
<wse:EndTo> <em>endpoint-reference</em> </wse:EndTo> ?
- <wse:Delivery Mode="<em>xs:anyURI</em>"? ...> <em>xs:any</em>* </wse:Delivery>
+ <wse:Delivery ...> <em>xs:any</em>* </wse:Delivery>
<wse:Format Name="<em>xs:anyURI</em>"? > <em>xs:any</em>* </wse:Format> ?
<wse:Expires> (<em>xs:dateTime</em> | <em>xs:duration</em>) </wse:Expires> ?
<wse:Filter Dialect="<em>xs:anyURI</em>"? ...> <em>xs:any</em>* </wse:Filter> ?
@@ -491,36 +462,22 @@
the subscription to which they apply MAY wish to add a
distinguishing reference parameter to the EndTo EPR.
</p></dd><dt class="label"><b>[Body]</b>/wse:Subscribe/wse:Delivery </dt><dd><p>
- A delivery destination for notification messages, using
- some delivery mode. See <a href="#DeliveryModes"><b>2.2 Delivery Modes</b></a>
- for details.
- </p></dd><dt class="label"><b>[Body]</b>/wse:Subscribe/wse:Delivery/@Mode </dt><dd><p>
- The delivery mode to be used for notification messages
- sent in relation to this subscription. Implied value is
- "http://www.w3.org/2009/02/ws-evt/DeliveryModes/Push",
- which indicates that Push Mode delivery should be used. See
- <a href="#DeliveryModes"><b>2.2 Delivery Modes</b></a> for
- details.
- </p><p>
- If the event source does not support the requested
- delivery mode, the request MUST fail, and the event source
- MUST generate a wse:DeliveryModeRequestedUnavailable fault
- indicating that the requested delivery mode is not
- supported.
- </p></dd><dt class="label"><b>[Body]</b>/wse:Subscribe/wse:Delivery/@Mode="http://www.w3.org/2009/02/ws-evt/DeliveryModes/Push"
- </dt><dd><p>
- Value of <b>[Body]</b>/wse:Subscribe/wse:Delivery MUST contain at
- least
- the single element, wse:NotifyTo, that contains the endpoint reference
- to which notification messages should be sent. The value of this
- element is not constrained for other delivery modes.
+ This element contains the information necessary to convey
+ notification messages from the event source to the event sink in
+ a manner required by the subscriber. This element MUST contain
+ at least one child element.
+ </p></dd><dt class="label"><b>[Body]</b>/wse:Subscribe/wse:Delivery/wse:NotifyTo </dt><dd><p>
+ This specification defines one OPTIONAL element, wse:NotifyTo, to
+ be used as a child of the wse:Delivery element. When present this
+ element indicates that notifications MUST be sent to the
+ EndpointReference identified by this element.
</p></dd><dt class="label"><b>[Body]</b>/wse:Subscribe/wse:Format </dt><dd><p>
This optional element contains
the delivery format to be used for notification messages sent in
relation to this subscription. Implied value is
"http://www.w3.org/2009/02/ws-evt/DeliveryFormats/Unwrap", which
indicates that unwraped delivery should be used. See
- Section <a href="#DeliveryModes"><b>2.2 Delivery Modes</b></a> for details.
+ Section <a href="#NotificationFormats"><b>2.3 Notification Formats</b></a> for details.
</p><p>
If the event source does not support the requested delivery
format, the request MUST
@@ -1285,31 +1242,22 @@
</p></dd><dt class="label"> /wse:RetryAfter/@any</dt><dd><p>
Optional extensibility attributes that do not affect processing.
</p></dd></dl></div><div class="div2">
-<h3><a name="ModeUnavailable" id="ModeUnavailable"/>6.2 DeliveryModeRequestedUnavailable</h3><p>
- This fault is sent when a Subscribe request specifies a
- delivery mode that is not supported by the event source.
- Optionally, this fault may contain a list of supported delivery
- mode URIs in the Detail property.
- </p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wse:DeliveryModeRequestedUnavailable</td></tr><tr><td><b>[Reason]</b></td><td>The requested delivery mode is not supported.</td></tr><tr><td><b>[Detail]</b></td><td>
- <wse:SupportedDeliveryMode> +
- <br/><em>Optional; one per delivery mode supported by the
- receiver</em></td></tr></tbody></table></div><div class="div2">
-<h3><a name="InvalidExpirationTime" id="InvalidExpirationTime"/>6.3 InvalidExpirationTime</h3><p>
+<h3><a name="InvalidExpirationTime" id="InvalidExpirationTime"/>6.2 InvalidExpirationTime</h3><p>
This fault is sent when a Subscribe request specifies an
expiration time that is in the past or an expiration duration of
zero.
</p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wse:InvalidExpirationTime</td></tr><tr><td><b>[Reason]</b></td><td>The expiration time requested is invalid.</td></tr><tr><td><b>[Detail]</b></td><td><em>none</em></td></tr></tbody></table></div><div class="div2">
-<h3><a name="UnsupportedExpirationType" id="UnsupportedExpirationType"/>6.4 UnsupportedExpirationType</h3><p>
+<h3><a name="UnsupportedExpirationType" id="UnsupportedExpirationType"/>6.3 UnsupportedExpirationType</h3><p>
This fault is sent when a Subscribe request specifies an
expiration time and the event source is only capable of accepting
expiration durations; for instance, if the event source does not
have access to absolute time.
</p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wse:UnsupportedExpirationType</td></tr><tr><td><b>[Reason]</b></td><td>Only expiration durations are supported.</td></tr><tr><td><b>[Detail]</b></td><td><em>none</em></td></tr></tbody></table></div><div class="div2">
-<h3><a name="FilteringNotSupported" id="FilteringNotSupported"/>6.5 FilteringNotSupported</h3><p>
+<h3><a name="FilteringNotSupported" id="FilteringNotSupported"/>6.4 FilteringNotSupported</h3><p>
This fault is sent when a Subscribe request contains a filter
and the event source does not support filtering.
</p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wse:FilteringNotSupported</td></tr><tr><td><b>[Reason]</b></td><td>Filtering is not supported.</td></tr><tr><td><b>[Detail]</b></td><td><em>none</em></td></tr></tbody></table></div><div class="div2">
-<h3><a name="FilteringRequestedUnavailable" id="FilteringRequestedUnavailable"/>6.6 FilteringRequestedUnavailable</h3><p>
+<h3><a name="FilteringRequestedUnavailable" id="FilteringRequestedUnavailable"/>6.5 FilteringRequestedUnavailable</h3><p>
This fault is sent when a Subscribe request specifies a filter
dialect that the event source does not support. Optionally, this
fault may contain a list of supported filter dialect URIs in the
@@ -1318,7 +1266,7 @@
<wse:SupportedDialect> +
<br/><em>Optional; one per filter dialect supported by the
receiver</em></td></tr></tbody></table></div><div class="div2">
-<h3><a name="EventSourceUnableToProcess" id="EventSourceUnableToProcess"/>6.7 EventSourceUnableToProcess</h3><p>
+<h3><a name="EventSourceUnableToProcess" id="EventSourceUnableToProcess"/>6.6 EventSourceUnableToProcess</h3><p>
This fault is sent when the event source is not capable of
fulfilling a Subscribe request for local reasons unrelated to the
specific request.
@@ -1326,7 +1274,7 @@
source has too many subscribers".</em></td></tr><tr><td><b>[Detail]</b></td><td>
<wse:RetryAfter> ?
<em>(Optional)</em></td></tr></tbody></table></div><div class="div2">
-<h3><a name="UnableToRenew" id="UnableToRenew"/>6.8 UnableToRenew</h3><p>
+<h3><a name="UnableToRenew" id="UnableToRenew"/>6.7 UnableToRenew</h3><p>
This fault is sent when the event source is not capable of
fulfilling a Renew request for local reasons unrelated to the
specific request.
@@ -1334,13 +1282,13 @@
source has too many subscribers".</em></td></tr><tr><td><b>[Detail]</b></td><td>
<wse:RetryAfter> ?
<em>(Optional)</em></td></tr></tbody></table></div><div class="div2">
-<h3><a name="InvalidMessage" id="InvalidMessage"/>6.9 InvalidMessage</h3><p>
+<h3><a name="InvalidMessage" id="InvalidMessage"/>6.8 InvalidMessage</h3><p>
If a request message does not comply with the corresponding
outline listed above, the request MUST fail and the event source
or subscription manager MUST generate the following fault
indicating that the request is invalid:
</p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wse:InvalidMessage</td></tr><tr><td><b>[Reason]</b></td><td>The message is not valid and cannot be processed.</td></tr><tr><td><b>[Detail]</b></td><td><em>The invalid message</em></td></tr></tbody></table></div><div class="div2">
-<h3><a name="DeliveryFormatRequestedUnavailable" id="DeliveryFormatRequestedUnavailable"/>6.10 DeliveryFormatRequestUnavailable</h3><p>
+<h3><a name="DeliveryFormatRequestedUnavailable" id="DeliveryFormatRequestedUnavailable"/>6.9 DeliveryFormatRequestUnavailable</h3><p>
This fault is sent when a Subscribe request specifies a delivery
format that is not supported by the event source. Optionally, this
fault may contain a list of supported delivery format URIs in the
@@ -1348,12 +1296,12 @@
</p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wse:DeliveryFormatRequestedUnavailable</td></tr><tr><td><b>[Reason]</b></td><td>The requested delivery format is not supported.</td></tr><tr><td><b>[Detail]</b></td><td>
<wse:SupportedDeliveryFormat> +
<br/><em> Optional, one per delivery format supported by the receiver.</em></td></tr></tbody></table></div><div class="div2">
-<h3><a name="EmptyFilter" id="EmptyFilter"/>6.11 EmptyFilter</h3><p>
+<h3><a name="EmptyFilter" id="EmptyFilter"/>6.10 EmptyFilter</h3><p>
This fault MAY be generated when an Event Source detects a
wse:Subscribe request containing a filter that, for whatever
reason, will never evaluate to true.
</p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wse:EmptyFilter</td></tr><tr><td><b>[Reason]</b></td><td>The wse:Filter would result in zero Notifications.</td></tr><tr><td><b>[Detail]</b></td><td><em> The wse:Filter value. </em></td></tr></tbody></table></div><div class="div2">
-<h3><a name="UnusableEPR" id="UnusableEPR"/>6.12 UnusableEPR</h3><p>
+<h3><a name="UnusableEPR" id="UnusableEPR"/>6.11 UnusableEPR</h3><p>
This fault MAY be generated when an Event Source detects
that the wse:NotifyTo or wse:EndTo EPR is unusable.
</p><table border="1"><tbody><tr><td><b>[Code]</b></td><td>s12:Sender</td></tr><tr><td><b>[Subcode]</b></td><td>wse:UnusableEPR</td></tr><tr><td><b>[Reason]</b></td><td>An EPR in the Subscribe request message is unusable.</td></tr><tr><td><b>[Detail]</b></td><td><em> The specific EPR that generated the error and why. </em></td></tr></tbody></table></div></div><div class="div1">
@@ -1563,7 +1511,7 @@
information to be retrieved. The WSDL will contain annotations
that identify a service as an event source and that identify
those messages that describe notification messages. The policy
- will specify the delivery modes and filter types supported by the
+ will specify the delivery extensions and filter types supported by the
event source.
</p><p>
To indicate that notification and solicit-response operations
@@ -1683,8 +1631,6 @@
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
- <xs:attribute name="Mode" type="xs:anyURI" use="optional"
- default="http://http://www.w3.org/2009/02/ws-evt/DeliveryModes/Push" />
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>
@@ -1767,9 +1713,6 @@
<!-- Used in a fault if there's an unsupported dialect -->
<xs:element name="SupportedDialect" type="xs:anyURI" />
- <!-- Used in a fault if there's an unsupported delivery mode -->
- <xs:element name="SupportedDeliveryMode" type="xs:anyURI" />
-
<!-- Used in a fault if there's an unsupported format name -->
<xs:element name="SupportedDeliveryFormat" type="xs:anyURI" />
@@ -2089,4 +2032,5 @@
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6916">6916</a></td></tr><tr><td> 2009/06/04 </td><td> DD </td><td> Added resolution of issue
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6986">6986</a></td></tr><tr><td> 2009/07/07 </td><td> DD </td><td> Added resolution of issue
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7039">7039</a></td></tr><tr><td> 2009/07/21 </td><td> DD </td><td> Added resolution of issue
- <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6980">6980</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6980">6980</a></td></tr><tr><td> 2009/07/28 </td><td> DD </td><td> Added resolution of issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=6692">6692</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
Received on Tuesday, 28 July 2009 23:13:18 UTC