- From: Doug Davis via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 03 Nov 2009 22:09:18 +0000
- To: public-ws-resource-access-notifications@w3.org
Update of /w3ccvs/WWW/2002/ws/ra/edcopies
In directory hutz:/tmp/cvs-serv9202
Modified Files:
wsenum.html wsenum.xml wseventing.html wseventing.xml
Log Message:
minor tweaks for consistency
Things like s/Notification/notification/
Index: wseventing.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wseventing.xml,v
retrieving revision 1.104
retrieving revision 1.105
diff -u -d -r1.104 -r1.105
--- wseventing.xml 3 Nov 2009 21:36:19 -0000 1.104
+++ wseventing.xml 3 Nov 2009 22:09:16 -0000 1.105
@@ -220,12 +220,12 @@
<p>
When the wse:NotifyTo element is used within the Delivery element it
- specifies the endpoint to which Notifications are sent. For delivery
+ specifies the endpoint to which notifications are sent. For delivery
to addressable endpoints this is sufficient. However, for
non-addressable endpoints some additional mechanisms are needed. A
subscription manager MAY choose to support mechanisms, such as the
<bibref ref="WSMC"/> specification, to enable delivery of
- Notifications to non-addressable endpoints. See the
+ notifications to non-addressable endpoints. See the
<bibref ref="WSMC"/> specification for more information, and an
example, of how this would work.
</p>
@@ -722,9 +722,9 @@
<label> Subscription </label>
<def>
<p>
- A registration of interest in receiving Notification messages from
- an Event Source. Subscriptions may be created, renewed, expired
- or cancelled. A Subscription is "active" when it has been created
+ A registration of interest in receiving notification messages from
+ an event source. Subscriptions may be created, renewed, expired
+ or cancelled. A subscription is "active" when it has been created
but has not been expired or cancelled.
</p>
</def>
@@ -944,8 +944,8 @@
<label> <kw>[Body]</kw>/wse:Subscribe/wse:Expires </label>
<def>
<p>
- This OPTIONAL element can be used by the Subscriber to indicate the
- expiration time of the requested Subscription. The value of this
+ This OPTIONAL element can be used by the subscriber to indicate the
+ expiration time of the requested subscription. The value of this
element indicates the desired expiration time for the subscription.
The implied default is indefinite (no expiry). The value of this
element MUST be between the values of the @min and @max attributes
@@ -963,10 +963,10 @@
<p>
The value of the wse:Expires element as well as those of its @min and
@max attributes MAY be either a duration (xs:duration) or a specific
- time (xs:dateTime). Event Sources and Subscription Managers MUST
+ time (xs:dateTime). Event sources and subscription managers MUST
accept duration values and MAY accept specific time values. Upon
- receiving a request that contains specific time values, an Event
- Source or Subscription Manager that does not support such value
+ receiving a request that contains specific time values, an event
+ source or subscription manager that does not support such value
types MUST fail the request and generate a
wse:UnsupportedExpirationType fault.
</p>
@@ -976,14 +976,14 @@
element and its attributes. For example, the element value may be a
duration while the @max attribute may be a specific time. Regardless
of the value types, it must be true that wse:Expires/@min <=
- wse:Expires <= wse:Expires/@max as interpreted by the Event Source
- or Subscription manager at the time the wse:Subscribe request is
+ wse:Expires <= wse:Expires/@max as interpreted by the event source
+ or subscription manager at the time the wse:Subscribe request is
processed. If this is not true, the request MUST fail and the
receiver MUST generate a wse:InvalidExpirationTime fault.
</p>
<p>
- If a Subscriber chooses to use specific time values in a request,
+ If a subscriber chooses to use specific time values in a request,
it is RECOMMENDED that these values include a time zone component.
Specific time values that lack a time zone will be interpreted in
the local time zone of the receiver.
@@ -1049,8 +1049,8 @@
<p>
It is possible for a Subscribe request to contain a filter that
- will never evaluate to true for the lifetime of the Subscription.
- If an Event Source detects this condition it MUST generate a
+ will never evaluate to true for the lifetime of the subscription.
+ If an event source detects this condition it MUST generate a
wse:EmptyFilter fault in response to the Subscribe request message.
</p>
</def>
@@ -1215,7 +1215,7 @@
<label> <kw>[Body]</kw>/wse:SubscribeResponse/wse:GrantedExpires </label>
<def>
<p>
- The expiration time assigned by the Event Source. The
+ The expiration time assigned by the event source. The
expiration time MAY be either a specific time or a duration
but MUST be of the same type as the wse:Expires element of
the corresponding request. If the corresponding request
@@ -1226,9 +1226,9 @@
<p>
When expressed as a duration, the wse:GrantedExpires element
designates a time interval that began at the moment the
- Subscription is created. Although this specification cannot dictate
- when, during the processing of a Subscribe request, a Subscription is
- created, the Event Source MUST start the expiration interval at or
+ subscription is created. Although this specification cannot dictate
+ when, during the processing of a Subscribe request, a subscription is
+ created, the event source MUST start the expiration interval at or
before it transmits the wse:SubscribeResponse message.
</p>
@@ -1955,7 +1955,7 @@
</example>
<p>
- Line (08) is the action IRI for Subscription End. Lines
+ Line (08) is the action IRI for SubscriptionEnd. Lines
(10-13) indicate the message is sent to the EndTo of the
subscribe request (lines (23-30) in <specref ref="Table4"/>).
Line (17) indicates the event source is shutting down, and
@@ -2376,7 +2376,7 @@
<head>EmptyFilter</head>
<p>
- This fault MAY be generated when an Event Source detects a
+ 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>
@@ -2395,7 +2395,7 @@
<tr>
<td><kw>[Reason]</kw></td>
- <td>The wse:Filter would result in zero Notifications.</td>
+ <td>The wse:Filter would result in zero notifications.</td>
</tr>
<tr>
@@ -2412,7 +2412,7 @@
<head>UnusableEPR</head>
<p>
- This fault MAY be generated when an Event Source detects
+ This fault MAY be generated when an event source detects
that the wse:NotifyTo or wse:EndTo EPR is unusable.
</p>
@@ -2704,7 +2704,7 @@
<p>
The mechanism for indicating that a binding or endpoint conforms to the
- WS-Eventing specification's definition of an Event Source
+ WS-Eventing specification's definition of an event source
is through the use of the Web Services
Policy - Framework <bibref ref="wspolicy"/> and Web Services Policy -
Attachment <bibref ref="wspolicyattach"/> specifications.
@@ -2727,7 +2727,7 @@
The wsevp:EventSource policy assertion is a nested policy container
assertion. The meaning of this assertion, when present in a policy
alternative, is that WS-Eventing is required to communicate with the
- subject and that the subject is a WS-Eventing Event Source.
+ subject and that the subject is a WS-Eventing event source.
</p>
<p>
@@ -2787,7 +2787,7 @@
<def>
<p>
When present, this OPTIONAL parameter indicates support for the
- specified Filter Dialect IRI.
+ specified filter dialect IRI.
</p>
</def>
</gitem>
@@ -2797,7 +2797,7 @@
<def>
<p>
When present, this OPTIONAL parameter indicates the maximum
- subscriptions expiration time that this endpoint will support.
+ subscription expiration time that this endpoint will support.
Note: a value of "PT0S" indicates that this endpoint supports
subscriptions with an infinite lifetime.
</p>
@@ -2809,7 +2809,7 @@
<def>
<p>
When present, this OPTIONAL parameter indicates support for the
- specified event delivery format Name URI.
+ specified event delivery format name URI.
</p>
</def>
</gitem>
@@ -2822,7 +2822,7 @@
<p>
The mechanism for indicating that a binding or endpoint conforms to the
- WS-Eventing specification's definition of a Subscription Manager
+ WS-Eventing specification's definition of a subscription manager
is through the use of the Web Services
Policy - Framework <bibref ref="wspolicy"/> and Web Services Policy -
Attachment <bibref ref="wspolicyattach"/> specifications.
@@ -2847,7 +2847,7 @@
The wsevp:SubscriptionManager policy assertion is a nested policy container
assertion. The meaning of this assertion, when present in a policy
alternative, is that WS-Eventing is required to communicate with the
- subject and that the subject is a WS-Eventing Subscription Manager.
+ subject and that the subject is a WS-Eventing subscription manager.
</p>
<p>
@@ -2887,7 +2887,7 @@
<p>
A policy assertion that specifies that WS-Eventing protocol MUST be
used when communicating with this endpoint and that the subject is
- a Subscription Manager. This assertion has Endpoint Policy Subject.
+ a subscription manager. This assertion has Endpoint Policy Subject.
</p>
</def>
</gitem>
@@ -3194,27 +3194,27 @@
<p>
There are many use cases for WS-Eventing in which it is necessary for the
- Subscriber and the Event Sink to know the structure and contents of the
- Notifications that can result from a successful Subscribe request. For
+ subscriber and the event sink to know the structure and contents of the
+ notifications that can result from a successful Subscribe request. For
example, a developer might wish to use WSDL-based tools to generate
- service stubs capable of marshalling and dispatching Notifications. In
+ service stubs capable of marshalling and dispatching notifications. In
addition to this, the effective use of filters (including those in the
XPath dialect defined in <specref ref="Subscribe"/> as well as other
dialects not defined in this specification) requires some knowledge of
- the schema of the Events over which the filter will be applied.
+ the schema of the events over which the filter will be applied.
</p>
<p>
- There are many ways in which an Event Source could describe and
- advertise the structure of the Events for which it will issue
- Notifications. To provide a basic level of interoperability, this
+ There are many ways in which an event source could describe and
+ advertise the structure of the events for which it will issue
+ notifications. To provide a basic level of interoperability, this
specification defines the following two OPTIONAL mechanisms, in
<specref ref="ETypes"/> and <specref ref="NWSDL"/>, for describing and
- advertising Event information. If an implementation of a WS-Eventing
- Event Source chooses to describe the structure of its Events and
+ advertising event information. If an implementation of a WS-Eventing
+ event source chooses to describe the structure of its events and
advertise this description, it is RECOMMENDED that at least one of
these mechanisms be used. Mechanisms other than these MAY be used
- to describe and advertise the structure of Events, but the definition
+ to describe and advertise the structure of events, but the definition
of such mechanisms is out of the scope of this specification.
</p>
@@ -3222,14 +3222,14 @@
<head>Event Types & Event Descriptions</head>
<p>
- A key concept in the description and advertisement of Event information
+ A key concept in the description and advertisement of event information
is the "Event Type". An Event Type is a description of the syntactic
- structure and value space of the set of Events that share that type.
+ structure and value space of the set of events that share that type.
Event Types are independent of both the WS-Eventing protocol and the
- format of the Notifications used to transmit those Events. For example,
- the following Notification, although transmitted using the Wrapped
+ format of the notifications used to transmit those events. For example,
+ the following notification, although transmitted using the Wrapped
Notification Format defined in <specref ref="Subscribe"/>, has the same
- Event Type as the Notification in <specref ref="Table13"/>:
+ Event Type as the notification in <specref ref="Table13"/>:
</p>
<example id="EDExample">
@@ -3297,7 +3297,7 @@
<def>
<p>
This element contains the declarations of all the Event Types that
- apply to a given context, such as a particular Event Source.
+ apply to a given context, such as a particular event source.
</p>
</def>
</gitem>
@@ -3360,7 +3360,7 @@
<p>
This OPTIONAL attribute provides a value for the various 'action'
properties and attributes which, depending upon the format of the
- Notification used to transmit the Event, serve as a potential aide
+ notification used to transmit the Event, serve as a potential aide
to identifying the semantics implied by the message. When not
present the implied value of this attribute is the concatentation
of the wse:EventDescription's targetNamespace attribute and
@@ -3405,7 +3405,7 @@
<div3>
<head>Retrieving Event Descriptions</head>
<p>
- Although there are many ways in which an Event Source can make its
+ Although there are many ways in which an event source can make its
EventDescriptions available, this specification RECOMMENDS the use of
the mechanisms described in WS-MetadataExchange <bibref ref="MEX"/>.
This specification defines the following IRI to serve as the Dialect
@@ -3419,7 +3419,7 @@
<p>
The value of the @Identifier attribute for this Metadata Section MUST
be equal to the value of its wse:EventDescriptions/@targetNamespace. An
- Event Source MUST NOT have more than one EventDescriptions document.
+ event source MUST NOT have more than one EventDescriptions document.
</p>
</div3>
@@ -3427,15 +3427,15 @@
<head>Bindings for Event Descriptions</head>
<p>
For any Notification Format it SHOULD be possible to determine how a
- given wse:eventType will appear on the wire as a Notification in a
- Subscription created with that format. The following sections define
- how wse:eventTypes bind to Notifications for the two Notification
+ given wse:eventType will appear on the wire as a notification in a
+ subscription created with that format. The following sections define
+ how wse:eventTypes bind to notifications for the two notification
Formats defined in this specification; Unwrapped and Wrapped.
Specifications or profiles that define additional Notification Formats
- SHOULD define how wse:eventTypes bind to the Notifications for those
+ SHOULD define how wse:eventTypes bind to the notifications for those
formats. In the absence of a mapping for a particular Notification
Format, implementations MAY provide a Notification WSDL (see below)
- that explicitly describes the Notification operations.
+ that explicitly describes the notification operations.
</p>
<div4>
@@ -3448,18 +3448,18 @@
<ulist>
<item>
<p>
- The <kw>[Action]</kw> property of the Notification has the value of
+ The <kw>[Action]</kw> property of the notification has the value of
the actionURI attribute of the wse:eventType element
- corresponding to the type of the Event being transmitted.
+ corresponding to the type of the event being transmitted.
</p>
</item>
<item>
<p>
- The <kw>[Body]</kw> property of the Notification
+ The <kw>[Body]</kw> property of the notification
has a single child element. This child element is an instance of
the Global Element Declaration referenced by the element attribute
of the wse:eventType element corresponding to the type of the
- Event being transmitted.
+ event being transmitted.
</p>
</item>
</ulist>
@@ -3477,7 +3477,7 @@
<p>
The /soap:Envelope/soap:Body/wse:Notify/@actionURI attribute of the
Wrapped Notification has the value of the actionURI attribute of
- the eventType element corresponding to the type of the Event
+ the eventType element corresponding to the type of the event
being transmitted.
</p>
</item>
@@ -3486,7 +3486,7 @@
The /soap:Envelope/soap:Body/wse:Notify element has a single child
element. This child element is an instance of the Global Element
Declaration referenced by the element attribute of the eventType
- element corresponding to the type of the Event being transmitted.
+ element corresponding to the type of the event being transmitted.
</p>
</item>
</ulist>
@@ -3499,12 +3499,12 @@
<head>Notification WSDLs</head>
<p>
- As described previously, Event Sources transmit Events to Event Sinks as
- SOAP messages called "Notifications". These Notifications MAY be
+ As described previously, event sources transmit events to event sinks as
+ SOAP messages called "Notifications". These notifications MAY be
described via a Web Services Description Language <bibref ref="WSDL11"/>
definitions element termed a "Notification WSDL". A Notification WSDL
- describes the interface that the Event Sink is required to implement to
- receive and process the Notifications that might result from a
+ describes the interface that the event sink is required to implement to
+ receive and process the notifications that might result from a
successful Subscribe request that used a particular Format IRI. The
following is an example of a Notification WSDL:
</p>
@@ -3551,7 +3551,7 @@
<div3>
<head>Retrieving Notification WSDLs</head>
<p>
- Although there are many ways in which an Event Source can make
+ Although there are many ways in which an event source can make
Notification WSDLs available, this specification RECOMMENDS the use of
the mechanisms described in WS-MetadataExchange <bibref ref="MEX"/>.
This specification defines the following IRI to serve as the Dialect
@@ -3579,17 +3579,17 @@
<div2>
<head>Multiple Event Information Metadata Sections</head>
<p>
- When WS-MetadataExchange is used to retrieve metadata about an Event
- Source, recipients of mex:Metadata elements that contain Metadata
+ When WS-MetadataExchange is used to retrieve metadata about an event
+ source, recipients of mex:Metadata elements that contain Metadata
Sections with both the
"http://www.w3.org/&wsevt.nsprefix;/ws-evt/EventDescriptions" and
"http://www.w3.org/&wsevt.nsprefix;/ws-evt/NotificationWSDL" dialects MUST
- regard these Metadata Sections as relating to the same set of Events.
+ regard these Metadata Sections as relating to the same set of events.
In cases where the mex:Metadata element contains multiple
Notification WSDLs (i.e. multiple Metadata Sections with a @Dialect
of "http://www.w3.org/&wsevt.nsprefix;/ws-evt/NotificationWSDL"), recipients MUST
similarly regard these Notification WSDLs as relating to the same set
- of Events although their Notification Formats differ.
+ of events although their Notification Formats differ.
</p>
</div2>
@@ -3999,11 +3999,11 @@
<head>WSDL for Standard Wrapped Delivery</head>
<p>
- If an Event Subscriber specifies the wrapped event delivery format
+ If an event subscriber specifies the wrapped event delivery format
http://www.w3.org/&wsevt.nsprefix;/ws-evt/DeliveryFormats/Wrap
- in the Subscribe request message, then the Event Sink MUST implement
- the following abstract WSDL and the Event Source MUST send the
- Notification messages wrapped in the element defined in the WSDL.
+ in the Subscribe request message, then the event sink MUST implement
+ the following abstract WSDL and the event source MUST send the
+ notification messages wrapped in the element defined in the WSDL.
</p>
<example>
Index: wseventing.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wseventing.html,v
retrieving revision 1.112
retrieving revision 1.113
diff -u -d -r1.112 -r1.113
--- wseventing.html 3 Nov 2009 21:36:19 -0000 1.112
+++ wseventing.html 3 Nov 2009 22:09:16 -0000 1.113
@@ -169,12 +169,12 @@
of delivery extensions.
</p><p>
When the wse:NotifyTo element is used within the Delivery element it
- specifies the endpoint to which Notifications are sent. For delivery
+ specifies the endpoint to which notifications are sent. For delivery
to addressable endpoints this is sufficient. However, for
non-addressable endpoints some additional mechanisms are needed. A
subscription manager MAY choose to support mechanisms, such as the
<a href="#WSMC">[WS-MakeConnection]</a> specification, to enable delivery of
- Notifications to non-addressable endpoints. See the
+ notifications to non-addressable endpoints. See the
<a href="#WSMC">[WS-MakeConnection]</a> specification for more information, and an
example, of how this would work.
</p></div><div class="div2">
@@ -423,9 +423,9 @@
A one-way message sent to indicate that an event, or events,
have occurred.
</p></dd><dt class="label"> Subscription </dt><dd><p>
- A registration of interest in receiving Notification messages from
- an Event Source. Subscriptions may be created, renewed, expired
- or cancelled. A Subscription is "active" when it has been created
+ A registration of interest in receiving notification messages from
+ an event source. Subscriptions may be created, renewed, expired
+ or cancelled. A subscription is "active" when it has been created
but has not been expired or cancelled.
</p></dd><dt class="label"> Subscriber </dt><dd><p>
A Web service that sends requests to create, renew, and/or
@@ -543,8 +543,8 @@
</p></dd><dt class="label"><b>[Body]</b>/wse:Subscribe/wse:Format@Name="http://www.w3.org/2009/09/ws-evt/DeliveryFormats/Wrap" </dt><dd><p>
Indicate the wrapped event delivery format.
</p></dd><dt class="label"><b>[Body]</b>/wse:Subscribe/wse:Expires </dt><dd><p>
- This OPTIONAL element can be used by the Subscriber to indicate the
- expiration time of the requested Subscription. The value of this
+ This OPTIONAL element can be used by the subscriber to indicate the
+ expiration time of the requested subscription. The value of this
element indicates the desired expiration time for the subscription.
The implied default is indefinite (no expiry). The value of this
element MUST be between the values of the @min and @max attributes
@@ -558,10 +558,10 @@
</p><p>
The value of the wse:Expires element as well as those of its @min and
@max attributes MAY be either a duration (xs:duration) or a specific
- time (xs:dateTime). Event Sources and Subscription Managers MUST
+ time (xs:dateTime). Event sources and subscription managers MUST
accept duration values and MAY accept specific time values. Upon
- receiving a request that contains specific time values, an Event
- Source or Subscription Manager that does not support such value
+ receiving a request that contains specific time values, an event
+ source or subscription manager that does not support such value
types MUST fail the request and generate a
wse:UnsupportedExpirationType fault.
</p><p>
@@ -569,12 +569,12 @@
element and its attributes. For example, the element value may be a
duration while the @max attribute may be a specific time. Regardless
of the value types, it must be true that wse:Expires/@min <=
- wse:Expires <= wse:Expires/@max as interpreted by the Event Source
- or Subscription manager at the time the wse:Subscribe request is
+ wse:Expires <= wse:Expires/@max as interpreted by the event source
+ or subscription manager at the time the wse:Subscribe request is
processed. If this is not true, the request MUST fail and the
receiver MUST generate a wse:InvalidExpirationTime fault.
</p><p>
- If a Subscriber chooses to use specific time values in a request,
+ If a subscriber chooses to use specific time values in a request,
it is RECOMMENDED that these values include a time zone component.
Specific time values that lack a time zone will be interpreted in
the local time zone of the receiver.
@@ -608,8 +608,8 @@
supported.
</p><p>
It is possible for a Subscribe request to contain a filter that
- will never evaluate to true for the lifetime of the Subscription.
- If an Event Source detects this condition it MUST generate a
+ will never evaluate to true for the lifetime of the subscription.
+ If an event source detects this condition it MUST generate a
wse:EmptyFilter fault in response to the Subscribe request message.
</p></dd><dt class="label"><a name="Dialect" id="Dialect"/><b>[Body]</b>/wse:Subscribe/wse:Filter/@Dialect </dt><dd><p>
Implied value is "http://www.w3.org/2009/09/ws-evt/Dialects/XPath10".
@@ -697,7 +697,7 @@
reference parameter to distinguish among the active
subscriptions.
</p></dd><dt class="label"><b>[Body]</b>/wse:SubscribeResponse/wse:GrantedExpires </dt><dd><p>
- The expiration time assigned by the Event Source. The
+ The expiration time assigned by the event source. The
expiration time MAY be either a specific time or a duration
but MUST be of the same type as the wse:Expires element of
the corresponding request. If the corresponding request
@@ -706,9 +706,9 @@
</p><p>
When expressed as a duration, the wse:GrantedExpires element
designates a time interval that began at the moment the
- Subscription is created. Although this specification cannot dictate
- when, during the processing of a Subscribe request, a Subscription is
- created, the Event Source MUST start the expiration interval at or
+ subscription is created. Although this specification cannot dictate
+ when, during the processing of a Subscribe request, a subscription is
+ created, the event source MUST start the expiration interval at or
before it transmits the wse:SubscribeResponse message.
</p><p>
If this element does not appear, then the subscription
@@ -1224,7 +1224,7 @@
(21) </wse:SubscriptionEnd>
(22) </s12:Body>
(23) </s12:Envelope></pre></div></div><p>
- Line (08) is the action IRI for Subscription End. Lines
+ Line (08) is the action IRI for SubscriptionEnd. Lines
(10-13) indicate the message is sent to the EndTo of the
subscribe request (lines (23-30) in <a href="#Table4">Example 4-1</a>).
Line (17) indicates the event source is shutting down, and
@@ -1381,12 +1381,12 @@
<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.8 EmptyFilter</h3><p>
- This fault MAY be generated when an Event Source detects a
+ 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">
+ </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.9 UnusableEPR</h3><p>
- This fault MAY be generated when an Event Source detects
+ 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 class="div2">
<h3><a name="UnknownSubscription" id="UnknownSubscription"/>6.10 UnknownSubscription</h3><p>
@@ -1524,7 +1524,7 @@
</p><div class="div2">
<h3><a name="iddiv2_1_2177" id="iddiv2_1_2177"/>9.1 EventSource Assertion</h3><p>
The mechanism for indicating that a binding or endpoint conforms to the
- WS-Eventing specification's definition of an Event Source
+ WS-Eventing specification's definition of an event source
is through the use of the Web Services
Policy - Framework <a href="#wspolicy">[WS-Policy]</a> and Web Services Policy -
Attachment <a href="#wspolicyattach">[WS-Policy Attachment]</a> specifications.
@@ -1541,7 +1541,7 @@
The wsevp:EventSource policy assertion is a nested policy container
assertion. The meaning of this assertion, when present in a policy
alternative, is that WS-Eventing is required to communicate with the
- subject and that the subject is a WS-Eventing Event Source.
+ subject and that the subject is a WS-Eventing event source.
</p><p>
In order to indicate that the subject supports WS-Eventing
but does not require its use, an additional policy alternative should
@@ -1570,19 +1570,19 @@
expiration time expressed as specific time (rather than duration).
</p></dd><dt class="label"> /wsevp:EventSource/wsevp:FilterDialect </dt><dd><p>
When present, this OPTIONAL parameter indicates support for the
- specified Filter Dialect IRI.
+ specified filter dialect IRI.
</p></dd><dt class="label"> /wsevp:EventSource/wsevp:MaxExpires </dt><dd><p>
When present, this OPTIONAL parameter indicates the maximum
- subscriptions expiration time that this endpoint will support.
+ subscription expiration time that this endpoint will support.
Note: a value of "PT0S" indicates that this endpoint supports
subscriptions with an infinite lifetime.
</p></dd><dt class="label"> /wsevp:EventSource/wsevp:FormatName </dt><dd><p>
When present, this OPTIONAL parameter indicates support for the
- specified event delivery format Name URI.
+ specified event delivery format name URI.
</p></dd></dl></div><div class="div2">
<h3><a name="iddiv2_1_2244" id="iddiv2_1_2244"/>9.2 SubscriptionManager Assertion</h3><p>
The mechanism for indicating that a binding or endpoint conforms to the
- WS-Eventing specification's definition of a Subscription Manager
+ WS-Eventing specification's definition of a subscription manager
is through the use of the Web Services
Policy - Framework <a href="#wspolicy">[WS-Policy]</a> and Web Services Policy -
Attachment <a href="#wspolicyattach">[WS-Policy Attachment]</a> specifications.
@@ -1601,7 +1601,7 @@
The wsevp:SubscriptionManager policy assertion is a nested policy container
assertion. The meaning of this assertion, when present in a policy
alternative, is that WS-Eventing is required to communicate with the
- subject and that the subject is a WS-Eventing Subscription Manager.
+ subject and that the subject is a WS-Eventing subscription manager.
</p><p>
In order to indicate that the subject supports WS-Eventing
but does not require its use, an additional policy alternative should
@@ -1624,7 +1624,7 @@
</p><dl><dt class="label"> /wsevp:SubscriptionManager </dt><dd><p>
A policy assertion that specifies that WS-Eventing protocol MUST be
used when communicating with this endpoint and that the subject is
- a Subscription Manager. This assertion has Endpoint Policy Subject.
+ a subscription manager. This assertion has Endpoint Policy Subject.
</p></dd><dt class="label"> /wsevp:SubscriptionManager/wsevp:DateTimeSupported </dt><dd><p>
When present, this OPTIONAL parameter indicates support for
expiration time expressed as specific time (rather than duration).
@@ -1785,36 +1785,36 @@
Available at <a href="http://www.w3.org/TR/xpath">http://www.w3.org/TR/xpath</a>.</dd></dl></div></div></div><div class="back"><div class="div1">
<h2><a name="Advertising" id="Advertising"/>A Advertising Event Information</h2><p>
There are many use cases for WS-Eventing in which it is necessary for the
- Subscriber and the Event Sink to know the structure and contents of the
- Notifications that can result from a successful Subscribe request. For
+ subscriber and the event sink to know the structure and contents of the
+ notifications that can result from a successful Subscribe request. For
example, a developer might wish to use WSDL-based tools to generate
- service stubs capable of marshalling and dispatching Notifications. In
+ service stubs capable of marshalling and dispatching notifications. In
addition to this, the effective use of filters (including those in the
XPath dialect defined in <a href="#Subscribe"><b>4.1 Subscribe</b></a> as well as other
dialects not defined in this specification) requires some knowledge of
- the schema of the Events over which the filter will be applied.
+ the schema of the events over which the filter will be applied.
</p><p>
- There are many ways in which an Event Source could describe and
- advertise the structure of the Events for which it will issue
- Notifications. To provide a basic level of interoperability, this
+ There are many ways in which an event source could describe and
+ advertise the structure of the events for which it will issue
+ notifications. To provide a basic level of interoperability, this
specification defines the following two OPTIONAL mechanisms, in
<a href="#ETypes"><b>A.1 Event Types & Event Descriptions</b></a> and <a href="#NWSDL"><b>A.2 Notification WSDLs</b></a>, for describing and
- advertising Event information. If an implementation of a WS-Eventing
- Event Source chooses to describe the structure of its Events and
+ advertising event information. If an implementation of a WS-Eventing
+ event source chooses to describe the structure of its events and
advertise this description, it is RECOMMENDED that at least one of
these mechanisms be used. Mechanisms other than these MAY be used
- to describe and advertise the structure of Events, but the definition
+ to describe and advertise the structure of events, but the definition
of such mechanisms is out of the scope of this specification.
</p><div class="div2">
<h3><a name="ETypes" id="ETypes"/>A.1 Event Types & Event Descriptions</h3><p>
- A key concept in the description and advertisement of Event information
+ A key concept in the description and advertisement of event information
is the "Event Type". An Event Type is a description of the syntactic
- structure and value space of the set of Events that share that type.
+ structure and value space of the set of events that share that type.
Event Types are independent of both the WS-Eventing protocol and the
- format of the Notifications used to transmit those Events. For example,
- the following Notification, although transmitted using the Wrapped
+ format of the notifications used to transmit those events. For example,
+ the following notification, although transmitted using the Wrapped
Notification Format defined in <a href="#Subscribe"><b>4.1 Subscribe</b></a>, has the same
- Event Type as the Notification in <a href="#Table13">Example 5-1</a>:
+ Event Type as the notification in <a href="#Table13">Example 5-1</a>:
</p><div class="exampleOuter">
<div class="exampleHeader"><a name="EDExample" id="EDExample"/>Example A-1: Hypothetical Wrapped Notification</div><div class="exampleInner"><pre>(01) <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
(02) xmlns:wsa="http://www.w3.org/2005/08/addressing"
@@ -1864,7 +1864,7 @@
constraints on the outlined listed above:
</p><dl><dt class="label"> /wse:EventDescription </dt><dd><p>
This element contains the declarations of all the Event Types that
- apply to a given context, such as a particular Event Source.
+ apply to a given context, such as a particular event source.
</p></dd><dt class="label"> /wse:EventDescription@targetNamespace </dt><dd><p>
This attribute defines the namespace affiliation of the Event Types
declared within the EventDescriptions element. Its value MUST be an
@@ -1891,7 +1891,7 @@
</p></dd><dt class="label"> /wse:EventDescriptions/wse:eventType/@actionURI </dt><dd><p>
This OPTIONAL attribute provides a value for the various 'action'
properties and attributes which, depending upon the format of the
- Notification used to transmit the Event, serve as a potential aide
+ notification used to transmit the Event, serve as a potential aide
to identifying the semantics implied by the message. When not
present the implied value of this attribute is the concatentation
of the wse:EventDescription's targetNamespace attribute and
@@ -1922,7 +1922,7 @@
"{http://www.example.org/oceanwatch}:WindReportType".
</p><div class="div3">
<h4><a name="iddiv3_1_2742" id="iddiv3_1_2742"/>A.1.1 Retrieving Event Descriptions</h4><p>
- Although there are many ways in which an Event Source can make its
+ Although there are many ways in which an event source can make its
EventDescriptions available, this specification RECOMMENDS the use of
the mechanisms described in WS-MetadataExchange <a href="#MEX">[WS-MetadataExchange]</a>.
This specification defines the following IRI to serve as the Dialect
@@ -1930,33 +1930,33 @@
</p><div class="exampleOuter"><div class="exampleInner"><pre>http://www.w3.org/2009/09/ws-evt/EventDescriptions</pre></div></div><p>
The value of the @Identifier attribute for this Metadata Section MUST
be equal to the value of its wse:EventDescriptions/@targetNamespace. An
- Event Source MUST NOT have more than one EventDescriptions document.
+ event source MUST NOT have more than one EventDescriptions document.
</p></div><div class="div3">
<h4><a name="iddiv3_1_2758" id="iddiv3_1_2758"/>A.1.2 Bindings for Event Descriptions</h4><p>
For any Notification Format it SHOULD be possible to determine how a
- given wse:eventType will appear on the wire as a Notification in a
- Subscription created with that format. The following sections define
- how wse:eventTypes bind to Notifications for the two Notification
+ given wse:eventType will appear on the wire as a notification in a
+ subscription created with that format. The following sections define
+ how wse:eventTypes bind to notifications for the two notification
Formats defined in this specification; Unwrapped and Wrapped.
Specifications or profiles that define additional Notification Formats
- SHOULD define how wse:eventTypes bind to the Notifications for those
+ SHOULD define how wse:eventTypes bind to the notifications for those
formats. In the absence of a mapping for a particular Notification
Format, implementations MAY provide a Notification WSDL (see below)
- that explicitly describes the Notification operations.
+ that explicitly describes the notification operations.
</p><div class="div4">
<h5><a name="iddiv4_1_2763" id="iddiv4_1_2763"/>A.1.2.1 Binding for Unwrapped Notifications</h5><p>
The information about an Event Type contained in the wse:eventType
element binds to a Unwrapped Notification for that type as follows:
</p><ul><li><p>
- The <b>[Action]</b> property of the Notification has the value of
+ The <b>[Action]</b> property of the notification has the value of
the actionURI attribute of the wse:eventType element
- corresponding to the type of the Event being transmitted.
+ corresponding to the type of the event being transmitted.
</p></li><li><p>
- The <b>[Body]</b> property of the Notification
+ The <b>[Body]</b> property of the notification
has a single child element. This child element is an instance of
the Global Element Declaration referenced by the element attribute
of the wse:eventType element corresponding to the type of the
- Event being transmitted.
+ event being transmitted.
</p></li></ul></div><div class="div4">
<h5><a name="iddiv4_1_2781" id="iddiv4_1_2781"/>A.1.2.2 Binding for Wrapped Notifications</h5><p>
The information about an Event Type contained in the eventType element
@@ -1964,21 +1964,21 @@
</p><ul><li><p>
The /soap:Envelope/soap:Body/wse:Notify/@actionURI attribute of the
Wrapped Notification has the value of the actionURI attribute of
- the eventType element corresponding to the type of the Event
+ the eventType element corresponding to the type of the event
being transmitted.
</p></li><li><p>
The /soap:Envelope/soap:Body/wse:Notify element has a single child
element. This child element is an instance of the Global Element
Declaration referenced by the element attribute of the eventType
- element corresponding to the type of the Event being transmitted.
+ element corresponding to the type of the event being transmitted.
</p></li></ul></div></div></div><div class="div2">
<h3><a name="NWSDL" id="NWSDL"/>A.2 Notification WSDLs</h3><p>
- As described previously, Event Sources transmit Events to Event Sinks as
- SOAP messages called "Notifications". These Notifications MAY be
+ As described previously, event sources transmit events to event sinks as
+ SOAP messages called "Notifications". These notifications MAY be
described via a Web Services Description Language <a href="#WSDL11">[WSDL11]</a>
definitions element termed a "Notification WSDL". A Notification WSDL
- describes the interface that the Event Sink is required to implement to
- receive and process the Notifications that might result from a
+ describes the interface that the event sink is required to implement to
+ receive and process the notifications that might result from a
successful Subscribe request that used a particular Format IRI. The
following is an example of a Notification WSDL:
</p><div class="exampleOuter">
@@ -2018,7 +2018,7 @@
(34) </wsdl:binding>
(35) </wsdl:definitions></pre></div></div><div class="div3">
<h4><a name="iddiv3_1_2808" id="iddiv3_1_2808"/>A.2.1 Retrieving Notification WSDLs</h4><p>
- Although there are many ways in which an Event Source can make
+ Although there are many ways in which an event source can make
Notification WSDLs available, this specification RECOMMENDS the use of
the mechanisms described in WS-MetadataExchange <a href="#MEX">[WS-MetadataExchange]</a>.
This specification defines the following IRI to serve as the Dialect
@@ -2034,17 +2034,17 @@
Notification WSDL document.
</p></div></div><div class="div2">
<h3><a name="iddiv2_1_2824" id="iddiv2_1_2824"/>A.3 Multiple Event Information Metadata Sections</h3><p>
- When WS-MetadataExchange is used to retrieve metadata about an Event
- Source, recipients of mex:Metadata elements that contain Metadata
+ When WS-MetadataExchange is used to retrieve metadata about an event
+ source, recipients of mex:Metadata elements that contain Metadata
Sections with both the
"http://www.w3.org/2009/09/ws-evt/EventDescriptions" and
"http://www.w3.org/2009/09/ws-evt/NotificationWSDL" dialects MUST
- regard these Metadata Sections as relating to the same set of Events.
+ regard these Metadata Sections as relating to the same set of events.
In cases where the mex:Metadata element contains multiple
Notification WSDLs (i.e. multiple Metadata Sections with a @Dialect
of "http://www.w3.org/2009/09/ws-evt/NotificationWSDL"), recipients MUST
similarly regard these Notification WSDLs as relating to the same set
- of Events although their Notification Formats differ.
+ of events although their Notification Formats differ.
</p></div></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">[XMLSchema - Part 1]</a>,
@@ -2417,11 +2417,11 @@
</portType>
</wsdl:definitions></pre></div></div></div><div class="div1">
<h2><a name="wrappedWSDL" id="wrappedWSDL"/>D WSDL for Standard Wrapped Delivery</h2><p>
- If an Event Subscriber specifies the wrapped event delivery format
+ If an event subscriber specifies the wrapped event delivery format
http://www.w3.org/2009/09/ws-evt/DeliveryFormats/Wrap
- in the Subscribe request message, then the Event Sink MUST implement
- the following abstract WSDL and the Event Source MUST send the
- Notification messages wrapped in the element defined in the WSDL.
+ in the Subscribe request message, then the event sink MUST implement
+ the following abstract WSDL and the event source MUST send the
+ notification messages wrapped in the element defined in the WSDL.
</p><div class="exampleOuter"><div class="exampleInner"><pre><definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
Index: wsenum.html
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wsenum.html,v
retrieving revision 1.82
retrieving revision 1.83
diff -u -d -r1.82 -r1.83
--- wsenum.html 3 Nov 2009 21:03:44 -0000 1.82
+++ wsenum.html 3 Nov 2009 22:09:15 -0000 1.83
@@ -275,7 +275,7 @@
<h3><a name="terms" id="terms"/>2.4 Terminology</h3><dl><dt class="label"> Consumer </dt><dd><p>
The Web service that is requesting the data
enumeration from the data source
- </p></dd><dt class="label"> Data source </dt><dd><p>
+ </p></dd><dt class="label"> Data Source </dt><dd><p>
A Web service that supports traversal using
enumeration contexts via the Enumerate operation defined in this
specification
Index: wsenum.xml
===================================================================
RCS file: /w3ccvs/WWW/2002/ws/ra/edcopies/wsenum.xml,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -d -r1.75 -r1.76
--- wsenum.xml 3 Nov 2009 21:03:44 -0000 1.75
+++ wsenum.xml 3 Nov 2009 22:09:15 -0000 1.76
@@ -485,7 +485,7 @@
</gitem>
<gitem>
- <label> Data source </label>
+ <label> Data Source </label>
<def>
<p>
A Web service that supports traversal using
Received on Tuesday, 3 November 2009 22:09:28 UTC