W3C home > Mailing lists > Public > public-ws-resource-access-notifications@w3.org > August 2009

WWW/2002/ws/ra/edcopies wseventing.html,1.77,1.78 wseventing.xml,1.68,1.69

From: Doug Davis via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 26 Aug 2009 13:14:31 +0000
To: public-ws-resource-access-notifications@w3.org
Message-Id: <E1MgIKd-0002gU-4A@lionel-hutz.w3.org>
Update of /w3ccvs/WWW/2002/ws/ra/edcopies
In directory hutz:/tmp/cvs-serv10227

Modified Files:
	wseventing.html wseventing.xml 
Log Message:
7160


Index: wseventing.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wseventing.xml,v
retrieving revision 1.68
retrieving revision 1.69
diff -u -d -r1.68 -r1.69
--- wseventing.xml	26 Aug 2009 03:25:10 -0000	1.68
+++ wseventing.xml	26 Aug 2009 13:14:29 -0000	1.69
@@ -116,13 +116,13 @@
     Web service (called a "subscriber") to register interest (called
     a "subscription") with another Web service (called an "event
     source") in receiving messages about events (called
-    "notifications"). The subscriber may manage
+    "notifications"). The subscriber can manage
     the subscription by interacting with a Web service (called the
     "subscription manager") designated by the event source.
    </p>
 
    <p>
-    To improve robustness, a subscription may be leased by an
+    To improve robustness, a subscription can be leased by an
     event source to a subscriber, and the subscription expires over
     time. The subscription manager provides the ability for the
     subscriber to renew or cancel the subscription before it
@@ -130,7 +130,7 @@
    </p>
 
    <p>
-    There are many mechanisms by which event sources may deliver
+    There are many mechanisms by which event sources can deliver
     events to event sinks. This specification provides an extensible
     way for subscribers to identify the delivery mechanism they
     prefer.
@@ -171,7 +171,7 @@
  
      <item>
       <p>
-       Allow subscribers to specify how notifications should be delivered.
+       Allow subscribers to specify how notifications are to be delivered.
       </p>
      </item>
  
@@ -214,7 +214,7 @@
      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 
+     methods or combination of methods MAY be defined through the use 
      of delivery extensions.
     </p>
 
@@ -237,7 +237,7 @@
     <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 defined by this 
+     MUST be contained in a wrapper element defined by this 
      specification. Use of unwrapped format indicates that notification 
      messages are not contained in a wrapper element.
     </p>
@@ -255,15 +255,15 @@
     <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
+     geographically distributed publish-and-subscribe system, it might
      be useful to delegate the management of a subscription to another
      Web service. To support this flexibility, the response to a
      subscription request to an event source will include the EPR of a
-     service that the subscriber may interact with to manage this
-     subscription. This EPR should be the target for future requests
-     to renew or cancel the subscription. It may address the same Web
+     service that the subscriber MAY interact with to manage this
+     subscription. This EPR MUST be the target for future requests
+     to renew or cancel the subscription. It can address the same Web
      service (Address and ReferenceParameters) as the event source
-     itself, or it may address some other Web service to which the
+     itself, or it can address some other Web service to which the
      event source has delegated management of this subscription;
      however, the full subscription manager EPR (Address and Reference
      Parameters) must be unique for each
@@ -331,12 +331,12 @@
     </p>
 
     <p>
-     While lines (13-15) indicate where a reply should be sent,
-     lines (20-29) indicate where and how notifications should be
+     While lines (13-15) indicate where a reply SHOULD be sent,
+     lines (20-29) indicate where and how notifications MUST be
      delivered; there is no requirement that these match. The absence
      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
+     MUST 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
@@ -765,11 +765,11 @@
    <p>
     When an event source accepts a request to create a
     subscription, it typically does so for a given amount of time,
-    although an event source may accept an indefinite subscription
+    although an event source MAY accept an indefinite subscription
     with no time-based expiration. If the subscription manager
     accepts a renewal request, it updates that amount of time. During
     that time, notifications are delivered by the event source to the
-    requested event sink. An event source may support filtering to
+    requested event sink. An event source MAY support filtering to
     limit notifications that are delivered to the event sink; if it
     does, and a subscribe request contains a filter, the event source
     sends only notifications that match the requested filter. The
@@ -870,7 +870,7 @@
         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 unwrapped delivery should be used. See 
+        indicates that unwrapped delivery MUST be used. See 
         Section <specref ref="NotificationFormats"/> for details.
        </p>
 
@@ -909,7 +909,7 @@
         implied value.) The event source defines the actual
         expiration and is not constrained to use a time less or
         greater than the requested expiration. The expiration time
-        may be a specific time or a duration from the subscription's
+        MAY be a specific time or a duration from the subscription's
         creation time. Both specific times and durations are
         interpreted based on the event source's clock.
        </p>
@@ -919,8 +919,8 @@
         subscription that will not expire. That is, the subscriber is
         requesting the event source to create a subscription with an
         indefinite lifetime. If the event source grants such a
-        subscription, it may be terminated by the subscriber using an
-        Unsubscribe request, or it may be terminated by the event
+        subscription, it MAY be terminated by the subscriber using an
+        Unsubscribe request, or it MAY be terminated by the event
         source at any time for reasons such as connection
         termination, resource constraints, or system shut-down.
        </p>
@@ -934,7 +934,7 @@
        </p>
 
        <p>
-        Some event sources may not have a "wall time" clock
+        Some event sources might not have a "wall time" clock
         available, and so are only able to accept durations as
         expirations. If such a source receives a Subscribe request
         containing a specific time expiration, then the request MAY
@@ -987,7 +987,7 @@
 
        <p>
         While an XPath predicate expression provides great
-        flexibility and power, alternate filter dialects may be
+        flexibility and power, alternate filter dialects MAY be
         defined. For instance, a simpler, less powerful dialect might
         be defined for resource-constrained implementations, or a new
         dialect might be defined to support filtering based on data
@@ -1131,8 +1131,8 @@
        <p>
         If this element does not appear, then the subscription
         will not expire. That is, the subscription has an indefinite
-        lifetime. It may be terminated by the subscriber using an
-        Unsubscribe request, or it may be terminated by the event
+        lifetime. It MAY be terminated by the subscriber using an
+        Unsubscribe request, or it MAY be terminated by the event
         source at any time for reasons such as connection
         termination, resource constraints, or system shut-down.
        </p>
@@ -2159,7 +2159,7 @@
     <p>
      This fault is generated 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
+     fault MAY contain a list of supported filter dialect URIs in the
      Detail property.
     </p>
 
@@ -2349,7 +2349,7 @@
     <p>
      This fault is generated 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 
+     fault MAY contain a list of supported delivery format URIs in the 
      Detail property.
     </p>
 
@@ -2471,15 +2471,15 @@
      messaging headers, such as those from WS-Addressing 
      <bibref ref="AddrCore"/>, need to be signed with the
      body in order to "bind" the two together. For messages with empty
-     bodies, the <code>&lt;s12:Body&gt;</code> element should be
+     bodies, the <code>&lt;s12:Body&gt;</code> element SHOULD be
      signed so content cannot be added in transit.
     </p>
 
     <p>
-     Different security mechanisms may be desired depending on the
+     Different security mechanisms MAY be desired depending on the
      frequency of messages. For example, for infrequent messages,
-     public key technologies may be adequate for integrity and
-     confidentiality. However, for high-frequency events, it may be
+     public key technologies MAY be adequate for integrity and
+     confidentiality. However, for high-frequency events, it MAY be
      more performant to establish a security context for the events
      using the mechanisms described in WS-Trust 
      <bibref ref="WSTrust"/> and WS-SecureConversation 
@@ -2487,7 +2487,7 @@
     </p>
 
     <p>
-     It should be noted that if a shared secret is used it is
+     Note that if a shared secret is used it is
      RECOMMENDED that derived keys be used to strengthen the secret as
      described in WS-SecureConversation.
     </p>
@@ -2553,16 +2553,16 @@
        described in WS-Security. Other attacks, such as
        network-level denial of service attacks are harder to avoid
        and are outside the scope of this specification. That said,
-       care should be taken to ensure that minimal state is saved
+       care SHOULD be taken to ensure that minimal state is saved
        prior to any authenticating sequences.
       </p>
      </item>
 
      <item>
       <p>
-        Replay  - Messages may be replayed
+        Replay  - Messages might be replayed
        for a variety of reasons. To detect and eliminate this
-       attack, mechanisms should be used to identify replayed
+       attack, mechanisms SHOULD be used to identify replayed
        messages such as the timestamp/nonce outlined in WS-Security.
        Alternatively, and optionally, other technologies, such as
        sequencing, can also be used to prevent replay of application
@@ -2629,9 +2629,9 @@
    </p>
 
    <p>
-    Event sinks should be prepared to receive notifications after
+    Event sinks SHOULD be prepared to receive notifications after
     sending a subscribe request but before receiving a subscribe
-    response message. Event sinks should also be prepared to receive
+    response message. Event sinks SHOULD also be prepared to receive
     notifications after receiving an unsubscribe response
     message.
    </p>
@@ -2831,7 +2831,7 @@
    <p>
     In order to obtain the event-related metadata that describes a
     service, the mechanisms described in WS-MetadataExchange
-    <bibref ref="MEX"/> should be used. The
+    <bibref ref="MEX"/> SHOULD be used. The
     GetMetadata operation defined there allows WSDL and policy
     information to be retrieved. The WSDL will contain annotations
     that identify a service as an event source and that identify
@@ -2953,9 +2953,9 @@
     As described here, to subscribe to events exposed by an event
     source, a subscribing endpoint sends a Subscribe message to the
     endpoint reference for the event source. If the Subscribe does
-    not include a filter, the event sink should expect to receive
+    not include a filter, the event sink SHOULD expect to receive
     events defined by notification operations within the portType and
-    should expect to receive and respond to events defined by
+    SHOULD expect to receive and respond to events defined by
     solicit-response operations within the portType.
    </p>
 
@@ -2970,7 +2970,7 @@
 
    <p>
     A normative copy of the XML Schema <bibref ref='XMLSchema1'/>,
-    <bibref ref='XMLSchema2'/> description for this specification may be
+    <bibref ref='XMLSchema2'/> description for this specification can be
     retrieved from the following address:
    </p>
 
@@ -3723,6 +3723,13 @@
        <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7235">7235</loc>
       </td>
      </tr>
+     <tr>
+      <td> 2009/08/26 </td>
+      <td> DD </td>
+      <td> Added resolution of issue 
+       <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7160">7160</loc>
+      </td>
+     </tr>
     </tbody>
    </table>
   </div1>

Index: wseventing.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wseventing.html,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -d -r1.77 -r1.78
--- wseventing.html	26 Aug 2009 03:25:10 -0000	1.77
+++ wseventing.html	26 Aug 2009 13:14:28 -0000	1.78
@@ -105,17 +105,17 @@
     Web service (called a "subscriber") to register interest (called
     a "subscription") with another Web service (called an "event
     source") in receiving messages about events (called
-    "notifications"). The subscriber may manage
+    "notifications"). The subscriber can manage
     the subscription by interacting with a Web service (called the
     "subscription manager") designated by the event source.
    </p><p>
-    To improve robustness, a subscription may be leased by an
+    To improve robustness, a subscription can be leased by an
     event source to a subscriber, and the subscription expires over
     time. The subscription manager provides the ability for the
     subscriber to renew or cancel the subscription before it
     expires.
    </p><p>
-    There are many mechanisms by which event sources may deliver
+    There are many mechanisms by which event sources can deliver
     events to event sinks. This specification provides an extensible
     way for subscribers to identify the delivery mechanism they
     prefer.
@@ -132,7 +132,7 @@
        Define how an event source delegates subscription
        management to another Web service.
       </p></li><li><p>
-       Allow subscribers to specify how notifications should be delivered.
+       Allow subscribers to specify how notifications are to be delivered.
       </p></li><li><p>
        Leverage other Web service specifications for secure,
        reliable, transacted message delivery.
@@ -152,7 +152,7 @@
      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 
+     methods or combination of methods MAY be defined through the use 
      of delivery extensions.
     </p><p>
      When the wse:NotifyTo element is used within the Delivery element it 
@@ -168,7 +168,7 @@
 <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 defined by this 
+     MUST be contained in a wrapper element defined by this 
      specification. Use of unwrapped format indicates that notification 
      messages are not contained in a wrapper element.
     </p><p>
@@ -179,15 +179,15 @@
 <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
+     geographically distributed publish-and-subscribe system, it might
      be useful to delegate the management of a subscription to another
      Web service. To support this flexibility, the response to a
      subscription request to an event source will include the EPR of a
-     service that the subscriber may interact with to manage this
-     subscription. This EPR should be the target for future requests
-     to renew or cancel the subscription. It may address the same Web
+     service that the subscriber MAY interact with to manage this
+     subscription. This EPR MUST be the target for future requests
+     to renew or cancel the subscription. It can address the same Web
      service (Address and ReferenceParameters) as the event source
-     itself, or it may address some other Web service to which the
+     itself, or it can address some other Web service to which the
      event source has delegated management of this subscription;
      however, the full subscription manager EPR (Address and Reference
      Parameters) must be unique for each
@@ -238,12 +238,12 @@
      indicates that it is sent to a hypothetical event source of ocean
      events.
     </p><p>
-     While lines (13-15) indicate where a reply should be sent,
-     lines (20-29) indicate where and how notifications should be
+     While lines (13-15) indicate where a reply SHOULD be sent,
+     lines (20-29) indicate where and how notifications MUST be
      delivered; there is no requirement that these match. The absence
      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
+     MUST 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
@@ -432,11 +432,11 @@
    </p><p>
     When an event source accepts a request to create a
     subscription, it typically does so for a given amount of time,
-    although an event source may accept an indefinite subscription
+    although an event source MAY accept an indefinite subscription
     with no time-based expiration. If the subscription manager
     accepts a renewal request, it updates that amount of time. During
     that time, notifications are delivered by the event source to the
-    requested event sink. An event source may support filtering to
+    requested event sink. An event source MAY support filtering to
     limit notifications that are delivered to the event sink; if it
     does, and a subscribe request contains a filter, the event source
     sends only notifications that match the requested filter. The
@@ -497,7 +497,7 @@
         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 unwrapped delivery should be used. See 
+        indicates that unwrapped delivery MUST be used. See 
         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 
@@ -513,7 +513,7 @@
         implied value.) The event source defines the actual
         expiration and is not constrained to use a time less or
         greater than the requested expiration. The expiration time
-        may be a specific time or a duration from the subscription's
+        MAY be a specific time or a duration from the subscription's
         creation time. Both specific times and durations are
         interpreted based on the event source's clock.
        </p><p>
@@ -521,8 +521,8 @@
         subscription that will not expire. That is, the subscriber is
         requesting the event source to create a subscription with an
         indefinite lifetime. If the event source grants such a
-        subscription, it may be terminated by the subscriber using an
-        Unsubscribe request, or it may be terminated by the event
+        subscription, it MAY be terminated by the subscriber using an
+        Unsubscribe request, or it MAY be terminated by the event
         source at any time for reasons such as connection
         termination, resource constraints, or system shut-down.
        </p><p>
@@ -532,7 +532,7 @@
         generate a wse:InvalidExpirationTime fault indicating that an
         invalid expiration time was requested.
        </p><p>
-        Some event sources may not have a "wall time" clock
+        Some event sources might not have a "wall time" clock
         available, and so are only able to accept durations as
         expirations. If such a source receives a Subscribe request
         containing a specific time expiration, then the request MAY
@@ -565,7 +565,7 @@
         Implied value is "http://www.w3.org/2009/02/ws-evt/Dialects/XPath10".
        </p><p>
         While an XPath predicate expression provides great
-        flexibility and power, alternate filter dialects may be
+        flexibility and power, alternate filter dialects MAY be
         defined. For instance, a simpler, less powerful dialect might
         be defined for resource-constrained implementations, or a new
         dialect might be defined to support filtering based on data
@@ -641,8 +641,8 @@
        </p><p>
         If this element does not appear, then the subscription
         will not expire. That is, the subscription has an indefinite
-        lifetime. It may be terminated by the subscriber using an
-        Unsubscribe request, or it may be terminated by the event
+        lifetime. It MAY be terminated by the subscriber using an
+        Unsubscribe request, or it MAY be terminated by the event
         source at any time for reasons such as connection
         termination, resource constraints, or system shut-down.
        </p></dd></dl><p>
@@ -1282,7 +1282,7 @@
 <h3><a name="FilteringRequestedUnavailable" id="FilteringRequestedUnavailable"/>6.5 FilteringRequestedUnavailable</h3><p>
      This fault is generated 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
+     fault MAY contain a list of supported filter dialect 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:FilteringRequestedUnavailable</td></tr><tr><td><b>[Reason]</b></td><td>The requested filter dialect is not supported.</td></tr><tr><td><b>[Detail]</b></td><td>
         &lt;wse:SupportedDialect&gt; + 
@@ -1318,7 +1318,7 @@
 <h3><a name="DeliveryFormatRequestedUnavailable" id="DeliveryFormatRequestedUnavailable"/>6.10 DeliveryFormatRequestUnavailable</h3><p>
      This fault is generated 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 
+     fault MAY contain a list of supported delivery format 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: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>
         &lt;wse:SupportedDeliveryFormat&gt; +
@@ -1343,19 +1343,19 @@
      messaging headers, such as those from WS-Addressing 
      <a href="#AddrCore">[WS-Addressing]</a>, need to be signed with the
      body in order to "bind" the two together. For messages with empty
-     bodies, the <code>&lt;s12:Body&gt;</code> element should be
+     bodies, the <code>&lt;s12:Body&gt;</code> element SHOULD be
      signed so content cannot be added in transit.
     </p><p>
-     Different security mechanisms may be desired depending on the
+     Different security mechanisms MAY be desired depending on the
      frequency of messages. For example, for infrequent messages,
-     public key technologies may be adequate for integrity and
-     confidentiality. However, for high-frequency events, it may be
+     public key technologies MAY be adequate for integrity and
+     confidentiality. However, for high-frequency events, it MAY be
      more performant to establish a security context for the events
      using the mechanisms described in WS-Trust 
      <a href="#WSTrust">[WS-Trust]</a> and WS-SecureConversation 
      <a href="#WSSecureConversation">[WS-SecureConversation]</a>.
     </p><p>
-     It should be noted that if a shared secret is used it is
+     Note that if a shared secret is used it is
      RECOMMENDED that derived keys be used to strengthen the secret as
      described in WS-SecureConversation.
     </p><p>
@@ -1395,12 +1395,12 @@
        described in WS-Security. Other attacks, such as
        network-level denial of service attacks are harder to avoid
        and are outside the scope of this specification. That said,
-       care should be taken to ensure that minimal state is saved
+       care SHOULD be taken to ensure that minimal state is saved
        prior to any authenticating sequences.
       </p></li><li><p>
-        Replay  - Messages may be replayed
+        Replay  - Messages might be replayed
        for a variety of reasons. To detect and eliminate this
-       attack, mechanisms should be used to identify replayed
+       attack, mechanisms SHOULD be used to identify replayed
        messages such as the timestamp/nonce outlined in WS-Security.
        Alternatively, and optionally, other technologies, such as
        sequencing, can also be used to prevent replay of application
@@ -1437,9 +1437,9 @@
     renew request and response messages that are significantly larger
     than expected network latency.
    </p><p>
-    Event sinks should be prepared to receive notifications after
+    Event sinks SHOULD be prepared to receive notifications after
     sending a subscribe request but before receiving a subscribe
-    response message. Event sinks should also be prepared to receive
+    response message. Event sinks SHOULD also be prepared to receive
     notifications after receiving an unsubscribe response
     message.
    </p></div><div class="div1">
@@ -1546,7 +1546,7 @@
 <h2><a name="Metadata" id="Metadata"/>A Service Metadata for Eventing</h2><p>
     In order to obtain the event-related metadata that describes a
     service, the mechanisms described in WS-MetadataExchange
-    <a href="#MEX">[WS-MetadataExchange]</a> should be used. The
+    <a href="#MEX">[WS-MetadataExchange]</a> SHOULD be used. The
     GetMetadata operation defined there allows WSDL and policy
     information to be retrieved. The WSDL will contain annotations
     that identify a service as an event source and that identify
@@ -1634,9 +1634,9 @@
     As described here, to subscribe to events exposed by an event
     source, a subscribing endpoint sends a Subscribe message to the
     endpoint reference for the event source. If the Subscribe does
-    not include a filter, the event sink should expect to receive
+    not include a filter, the event sink SHOULD expect to receive
     events defined by notification operations within the portType and
-    should expect to receive and respond to events defined by
+    SHOULD expect to receive and respond to events defined by
     solicit-response operations within the portType.
    </p><p>
     Editor's Note: We anticipate that this WSDL extension
@@ -1644,7 +1644,7 @@
    </p></div><div class="div1">
 <h2><a name="Schema" id="Schema"/>B XML Schema</h2><p>
     A normative copy of the XML Schema <a href="#XMLSchema1">[XML Schema, Part 1]</a>,
-    <a href="#XMLSchema2">[XML Schema, Part 2]</a> description for this specification may be
+    <a href="#XMLSchema2">[XML Schema, Part 2]</a> description for this specification can be
     retrieved from the following address:
    </p><div class="exampleOuter"><div class="exampleInner"><pre><a href="http://www.w3.org/2009/02/ws-evt/eventing.xsd">http://www.w3.org/2009/02/ws-evt/eventing.xsd</a></pre></div></div><p>
     A non-normative copy of the XML schema is listed below for
@@ -2081,4 +2081,5 @@
        <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7206">7206</a></td></tr><tr><td> 2009/08/25 </td><td> DD </td><td> Added resolution of issue 
        <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7365">7365</a></td></tr><tr><td> 2009/08/25 </td><td> DD </td><td> Added resolution of issue 
        <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7270">7270</a></td></tr><tr><td> 2009/08/25 </td><td> DD </td><td> Added resolution of issue 
-       <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7235">7235</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=7235">7235</a></td></tr><tr><td> 2009/08/26 </td><td> DD </td><td> Added resolution of issue 
+       <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=7160">7160</a></td></tr></tbody></table></div></div></body></html>
\ No newline at end of file
Received on Wednesday, 26 August 2009 13:14:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 26 August 2009 13:14:41 GMT