&scenario.name;

%entities; ]>

&scenario.name;

&scenario.w3c-designation;

"&scenario.w3c-doctype;

&scenario.day; &scenario.month; &scenario.year; &scenario.dated; http://www.w3.org/TR/&scenario.shortname; &prev.scenario.dated; Gilbert Pilz Oracle

This is the First Public Working Draft.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and can be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The following scenario is designed to provide a framework in which to test the interoperability of various WS-Eventing implementations. Because this scenario and the tests defined within it will be used to judge which features of WS-Eventing are implemented and which are not, the feature coverage is intended to be complete.

English

Last Modified: $Date: 2011/09/23 13:19:06 $

Dependencies Scope

The following specifications and technologies are in scope for this scenario:

SOAP 1.1

WS-MetadataExchange

WS-Eventing

WS-EventDescription

WS-MakeConnection

WS-Policy

WS-Transfer

WS-Fragment

WS-Enumeration

WS-SOAPAssertions

WSDL 1.1

XML Namespaces

lists XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.

Prefixes and XML namespaces used in this specification
Prefix	XML Namespaces	Specification(s)
s	(Either SOAP 1.1 or 1.2)	(Either SOAP 1.1 or 1.2)
s11	http://schemas.xmlsoap.org/soap/envelope/
s12	http://www.w3.org/2003/05/soap-envelope
xsd	http://www.w3.org/2001/XMLSchema
wsdl	http://schemas.xmlsoap.org/wsdl/
wsa	http://www.w3.org/2005/08/addressing
wse	http://www.w3.org/2011/03/ws-evt
evd	http://www.w3.org/2011/03/ws-evd
wsen	http://www.w3.org/2011/03/ws-enu
wsf	http://www.w3.org/2011/03/ws-fra
mex	http://www.w3.org/2011/03/ws-mex
wst	http://www.w3.org/2011/03/ws-tra
wss	http://www.w3.org/2011/03/ws-sas
sce	http://www.w3.org/2002/ws/ra/test/scenario	This document
gpx	http://www.topografix.com/GPX/1/1	GPS eXchange Format

Preconditions Notations and Terminology

This section specifies the notations, namespaces, and terminology used in this specification.

Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .

This specification uses the following syntax to define normative outlines for messages:

The syntax appears as an XML instance, but values in italics indicate data types instead of values.

Characters are appended to elements and attributes to indicate cardinality:

"?" (0 or 1)

"*" (0 or more)

"+" (1 or more)

The character "|" is used to indicate a choice between alternatives.

The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.

The characters "[" and "]" are used to call out references and property names.

Ellipsis (i.e. "...") indicate a point of extensibility.

Scenario Description

This scenario presupposes a cetacean tracking system in which a number of animals have been 'tagged' with devices that track their location. These tags periodically communicate via satellite to a central system. External systems can consume this information by using WS-Eventing to subscribe to periodic notifications about the locations of the tags and, presumably, the animals they are attached to. Systems may also query for the current data associated with an animal via WS-Enumeation, to enumerate the list of animals, or WS-Transfer/Fragment to retrieve the information about one particular animal. By using WS-MetadataExchange a client can determine which of the various WS-RA specifications are supported.

A set of properties is maintained for each animal that is tagged. The following properties are stored:

Properties for each animal
Property	Description	Example
ID	A GUID that uniquely identifies the animal	13c76450-de3d-11df-85ca-0800200c9a66
Name	The name given to the animal	Howard
Birthdate	The day on which the animal was born	2006-12-08
Gender	The gender of the animal	Male
Family	The Family of which the animal is a member	Eschrichtiidae
Genus	The Genus of which the animal is a member	Eschrichtius
Species	The Species of which the animal is a member	robustus
Current Location	The current GPS location of the animal

The XML representation of each tag will match the following pseudo-schema:

<sce:Animal ...> <sce:ID> xs:string </sce:ID> <sce:Name> xs:string </sce:Name> <sce:Birthdate> xs:dateTime </sce:Birthdate> <sce:Gender> xs:string </sce:Gender> <sce:Family> xs:string </sce:Family> <sce:Genus> xs:string </sce:Genus> <sce:Species> xs:string </sce:Species> <sce:CurrentLocation> xs:any </sce:CurrentLocation> <sce:EPR> wsa:endpoint-reference to this Animal </sce:EPR> ? <sce:History> <sce:Entry Date="xs:date"? Who="xs:string"? ...> xs:string </sce:Entry> * <sce:/History> xs:any </sce:Animal>

The location of the tags is expressed in GPS coordinates using the GPS eXchange Format, an XML schema designed as a common GPS data format for software applications. In addition to the basic GPS information (latitude, longitude, elevation, and time), the Animal's XML represenation includes an ID that uniquely identifies the tag and, by inference, the animal that the tag is attached to.

Predefined Animals/Tags

At a minimum each service side implementation of this scenario MUST initially have at least the following animals/tags:

ID: -- system defined -- Name: Howard Birthdate: 12/08/2006 Gender: Male Family: Eschrichtiidae Genus: Eschrichtius Species: robustus

ID: -- system defined -- Name: Kerry Birthdate: 05/22/2008 Gender: Female Family: Delphinidae Genus: Orcinus Species: orca

ID: -- system defined -- Name: Oscar Birthdate: 03/01/2010 Gender: Male Family: Balaenopteridae Genus: Megaptera Species: novaeangliae

Events

This scenario defines several events that MUST be generated if the service implementation supports WS-Eventing. The following events are defined:

NewAnimal

Generated when a new Animal is added to the tracking system.

UpdateLocation

Generated when an Animal's locationis updated. While in the real world the frequency of this event might be hourly or even daily, for the sake of feasibility we compress time by a scale of 1/120 so that one hour in 'scenario time' is thirty seconds in real-world time. The time data contained in the notifications will reflect scenario time.

UpdateAnimal

Generated when an Animal's data is updated in the tracking system. Note that this event is different from the updating of the GPS coordinate property. This event is sent when any other property (e.g. Name) is updated.

RemoveAnimal

Generated when an Animal is removed to the tracking system.

Each of the event that are generated will include the full XML represenation of the Animal within the Body of the event. An EventDescriptions document that describes the structure of the event information within the notifications can be found in .

Structure of Test Sections

The following sections describe tests designed to exercise all the mandatory and optional features of indicated specifications. Each of these tests is organized into four parts:

An overview that describes the purpose of the test and the salient features of the messages that are exchanged.

An optional sequence diagram that illustrates the sequence of events in the test.

A list of criteria used to judge the success of the test.

A conformance section that enumerates the conditions under which conforming implementations are allowed to either not implement the test or fail one or more of the success criteria.

Scenario Header

Some of the tests in this document require specialized logic by the service in order to create the situations described by the tests. This document defines a SOAP Header that can be used to convey which test is being executed, as well as any other additional information, to allow the service to perform the appropriate actions.

The outline of this header is:

<sce:Scenario ...> <sce:Test> x.y </sce:Test> <sce:EndTime> xs:duration | xs:dateTime </sce:EndTime> ... </sce:Scenario>

Where "x.y" is the test number. Certain tests define additional elements that might appear as children of the sce:Scenario element.

WS-MetadataExchange Tests

This sections describes the tests for WS-MetadataExchange. These tests are focused on testing the protocol itself and not necessarily on the metadata transported via the protocol.

GetWSDL Test

This test verifies the ability to retrieve the WSDL associated with a WS-MetadataExchange compliant service.

Sequence

...

Success Criteria

Receipt of a valid GetWSDL message by the service.

Receipt of a valid GetWSDLResponse message by the client.

Conformance

A conforming service MUST respond to the GetWSDL request with a GetWSDLResponse message. However, it MAY either include the WSDL of the service or no child elements at all as children of the GetWSDLResponse element.

Empty GetMetadata Test

This test verifies the ability to retrieve Metadata using the GetMetadata operation. In this test the GetMetadata request will not contain any child elements. In other words, the client is asking for all available metadata to be returned.

Sequence

...

Success Criteria

Receipt of a valid (empty) GetMetadata message by the service.

Receipt of a valid GetMetadataResponse message by the client.

Conformance

A conforming service MUST respond to the GetMetadata request with a GetMetadataResponse message. The exact Metadata returned, if any, and the content form of the Metadata will vary depending on the availble metadata from the service. At a minimum it is expected that the WSDL of the service MUST be returned.

WSDL GetMetadata Test

This test verifies the ability to retrieve Metadata using the GetMetadata operation. In this test the client will specifically ask for the WSDL of the service.

Sequence

...

Success Criteria

Receipt of a valid GetMetadata message, requesting the WSDL, by the service.

Receipt of a valid GetMetadataResponse message, containing the WSDL, by the client.

Conformance

A conforming service MUST respond to the GetMetadata request with a GetMetadataResponse message. The response message MUST contain the WSDL of the service.

Variations

The GetMetadata request contains a Dialect@Content attribute set to 'EPR'. The response will either be a MetadataSection with a reference/EPR to the WSDL, or no MetadataSecton at all for this Type/Identifier/Content triplet.

The GetMetadata request contains a Dialect@Content attribute set to 'URI'. The response will either be a MetadataSection with a reference/URI to the WSDL, or no MetadataSecton at all for this Type/Identifier/Content triplet.

The GetMetadata request contains a Dialect@Content attribute set to 'Metadata'. The response will either be a MetadataSection with a the WSDL, or no MetadataSecton at all for this Type/Identifier/Content triplet.

The GetMetadata request contains a Dialect@Content attribute set to 'Any'. The response will either be a set of MetadataSections with a references to the WSDL, or the WSDL itself. Note that the exact set is service specific and can be empty.

The GetMetadata request contains a Dialect@Content attribute set to 'All'. The response will either be a set of MetadataSections with a references to the WSDL, or the WSDL itself. Note, that the result will contain all possible forms of the WSDL. The result will include all forms of WSDL returned by the previous variations.

The GetMetadata request contains a Dialect@Identifier attribute. The result will only contain WSDL documents that match this value.

The GetMetadata request contains a GetMetadata@Content attribute but the Dialect@Content attribute is absent. The result should match the @Content value specified.

The GetMetadata request contains a GetMetadata@Content attribute set to an unknown URI. The result should not contain any metadata.

Unknown GetMetadata Test

This test verifies the ability ask for unknown Metadata using the GetMetadata operation. In this test the client will specifically ask for an unknown Metadata type and the service is expected to ignore the request.

Sequence

...

Success Criteria

Receipt of a valid GetMetadata message, requesting an unknown Metadata type, by the service.

Receipt of a valid GetMetadataResponse message, containing no MetadataSections, by the client.

Conformance

A conforming service MUST respond to the GetMetadata request with a GetMetadataResponse message. The response message MUST contain zero MetadataSection elements.

MultiMetadata GetMetadata Test

This test verifies the ability ask for multiple types of Metadata at the same time using the GetMetadata operation. In this test the client will specifically ask for multiple types of Metadata (both known and unknown types) and the service is expected to process each type appropriately.

Sequence

...

Success Criteria

Receipt of a valid GetMetadata message by the service. The request MUST contain more than one mex:Dialect child element, and MUST contain at least one known and one unknown Metadata Type request.

Receipt of a valid GetMetadataResponse message by the client.

Conformance

A conforming service MUST respond to the GetMetadata request with a GetMetadataResponse message. The response MUST contain the appropriate MetadataSections based on the request.

PutMetadata Test

This test verifies the ability to update Metadata using the PutMetadata operation. In this case the client will update the WS-EventDescriptions metadata associated with the Tracker service.

Sequence

...

Success Criteria

Receipt of a valid PutMetadata message by the service.

Receipt of a valid PutMetadataResponse message by the client.

Conformance

A conforming service MUST respond to the PutMetadata request with a PutMetadataResponse message. Each service will decide which type of Metadata it will allow clients to update, as will as the content form.

DeleteMetadata Test

This test verifies the ability to update Metadata using the DeleteMetadata operation. The client will request the deletion of the WS-EventingDescription metadata.

Sequence

...

Success Criteria

Receipt of a valid DeleteMetadata message by the service.

Receipt of a valid DeleteMetadataResponse message by the client.

Conformance

A conforming service MUST respond to the DeleteMetadata request with a DeleteMetadataResponse message. Each service will decide which type of Metadata it will allow clients to delete.

WS-Eventing Tests

This section describes the tests for WS-Eventing except for those (such as the use of EventDescriptions or Notification WSDLs) that affect only the process of developing one or more of the components of a WS-Eventing-based system.

Basic Test

This test verifies the ability to subscribe and receive notifications. The initial Subscribe request has the following features:

expiration time chose by Event Source/Subscription Manager - ie. no Expires

no EndTo EPR

no Filters

unwrapped notifications - ie. no Format element

Sequence

The following diagram illustrates the sequence of messages for the Basic Test.

Success Criteria

Receipt of a valid Subscribe message by the Event Source.

Receipt of a valid SubscribeResponse message by Subscriber.

Receipt of one or more unwrapped Notifications by the Event Sink.

Receipt of a valid Unsubscribe message by the Subscription Manager.

Receipt of a valid UnsubscribeResponse message by the Subscriber.

Conformance

Because this test involves only operations and elements that are required, there are no allowable failure cases.

Any failure to meet the above success criteria indicates that either, or both, of the implementations participating in the test do not conform to WS-Eventing.

An implementation that is unable to support this test does not conform to WS-Eventing.

Variations

The Subscribe request contains a Format element with the Unwrapped URI. The results of this variant should be the same as specified above.

The Subscribe request contains unknown (random) elements within the Delivery element. The results of this variant should be the same as specified above.

The Subscribe request contains an Expires element with a duration value of "PT0S". The results of this variant should be the same as specified above.

The Subscribe request contains an Expires element with a large duration value - e.g. "PT100000000S". The results of this variant should be the same as specified above.

Wrapped Notifications

This test verifies the simple ability to subscribe and receive wrapped notifications. The initial Subscribe request has the following features:

expiration time chosen by Event Source/Subscription Manager

no EndTo EPR

no Filters

wrapped notifications

Sequence

The messaging sequence for this test is identical to that of the Basic Test.

Success Criteria

Receipt of a valid Subscribe message by the Event Source.

Receipt of a valid SubscribeResponse message by Subscriber.

Receipt of one or more wrapped Notifications by the Event Sink.

Receipt of a valid Unsubscribe message by the Subscription Manager.

Receipt of a valid UnsubscribeResponse message by the Subscriber.

Conformance

Because this test involves the use of the optional wrapped delivery format, there are a number of failure cases that fall within the boundaries of conforming behavior.

A conforming Subscriber/Event Sink MAY NOT be capable of implementing this test due to its inability to support wrapped notifications.

A conforming Event Source MAY respond to the initial Subscribe request with a wse:DeliveryFormatRequestUnavailable fault.

Duration Expiration Test

This test verifies the correct implementation of the expiration feature on the Event Source/Subscription Manager. The initial Subscribe message has the following features:

(short) expiration time chosen by Subscriber as xs:duration

no EndTo EPR

no Filters

unwrapped notifications

Sequence

The following diagram illustrates the sequence of messages for the Duration Expiration Test. Note that the Subscriber waits until the expiration time has passed before sending the GetStatus request.

Success Criteria

Receipt of a valid Subscribe message by the Event Source.

Receipt of a valid SubscribeResponse message by Subscriber.

Receipt of one or more unwrapped Notifications by the Event Sink.

Receipt of a valid GetStatus message by the Subscription Manager.

Receipt, by the Subscriber, of either the 'UnknownSubscription' fault (defined by Section 6.10 of WS-Eventing), a SOAP fault that indicates that the Subscription Manager no longer exists, or an HTTP error (i.e. '404') that indicates the Subscription Manager no longer exists

Conformance

Because this test involves the use of the optional wse:Expires element, a conforming Subscriber MAY NOT be capable of implementing this test due to its inability to support wse:Expires.

Note that, because wse:Expires is sender-optional and support for xs:duration is required, there are no valid reasons for a conforming Event Source/Subscription Manager implementation to either be unable to implement this test or to fail to meet one of the defined success criteria.

Variations

The results of this variant should be the same as specified above.

Specific Time Expiration Test

This test verifies the correct implementation of the expiration feature on the Event Source/Subscription Manager. The initial Subscribe request has the following features:

(short) expiration time chosen by Subscriber as xs:dateTime

no EndTo EPR

no Filters

unwrapped notifications

Sequence

The messaging sequence for this test is identical to that of the Duration Expiration Test.

Success Criteria

Receipt of a valid Subscribe message by the Event Source.

Receipt of a valid SubscribeResponse message by Subscriber.

Receipt of one or more unwrapped Notifications by the Event Sink.

Receipt of a valid GetStatus message by the Subscription Manager.

Conformance

Because this test involves the use of both the optional wse:Expires element and the optional xs:dateTime type, there are a number of failure cases that fall within the boundaries of conforming behavior.

A conforming Subscriber MAY NOT be capable of implementing this test either due to its inability to support the wse:Expires element or the xs:dateTime type.

A conforming Event Source MAY respond to the initial Subscribe request with a wse:UnsupportedExpirationType fault.

Best Effort Expiration Test

This test verifies the correct implementation of the 'best effort' expiration feature on the Event Source/Subscription Manager. The initial subscription has the following features:

expiration time chosen by Subscriber as xs:duration with @BestEffort ='true'

no EndTo EPR

no Filters

unwrapped notifications

Sequence

The messaging sequence for this test is identical to that of the Duration Expiration Test.

Success Criteria

Receipt of a valid Subscribe message by the Event Source.

Receipt of a valid SubscribeResponse message by Subscriber.

Receipt of one or more unwrapped Notifications by the Event Sink.

Receipt of a valid GetStatus message by the Subscription Manager.

Conformance

Because this test involves the use of both the optional wse:Expires element and the optional BestEffort attribute, there are a number of failure cases that fall within the boundaries of conforming behavior.

A conforming Subscriber MAY NOT be capable of implementing this test either due to its inability to support the wse:Expires element or the BestEffort attribute.

Note that, because both wse:Expires and BestEffort are sender-optional, there are no valid reasons for a conforming Event Source/Subscription Manager implementation to either be unable to implement this test or to fail to meet one of the defined success criteria.

Renew Test

This test verifies the ability of a Subscriber to update the expiration time of a Subscription via a Renew request. The initial Subscribe request has the following features:

(short) expiration time chosen by Subscriber as xs:duration

no EndTo EPR

no Filter

unwrapped notifications

The Renew request has the following features:

(short) expiration time chosen by Subscriber as xs:duration

Sequence

The following diagram illustrates the sequence of messages for the Renew Test.

Success Criteria

Receipt of a valid Subscribe message by the Event Source.

Receipt of a valid SubscribeResponse message by Subscriber.

Receipt of one or more wrapped Notifications by the Event Sink.

Prior to the expiration time elapsing, receipt of a valid Renew message by the Subscription Manager.

Receipt of a valid RenewResponse message by the Subscriber.

Subsequent to the Renew/RenewResponse exchange, receipt of one or more wrapped Notifications by the Event Sink.

Receipt of a valid Unsubscribe message by the Subscription Manager.

Receipt of a valid UnsubscribeResponse message by the Subscriber.

Conformance

Because this test involves the use of the optional wse:Expires element, a conforming Subscriber MAY NOT be capable of implementing this test due to its inability to support wse:Expires.

SubscriptionEnd Test

This test verifies the correct implementation of the SubscriptionEnd feature for both the Subscription Manager and the target of the SubscriptionEnd message. The initial Subscribe request has the following features:

expiration time chosen by Event Source/Subscription Manager

EndTo EPR

no Filters

unwrapped notifications

Note: this test requires the client to include an additional element in the sce:Scenario header:

<sce:EndTime> xs:duration | xs:dateTime </sce:EndTime>

The duration/time specified by this element indicates when the event source is to "unexceptedly" terminate the subscription, thus causes the SubscriptionEnd message to be sent. The value specified in this element must be less than the expires time specified in the Subscribe request message.

Sequence

The following diagram illustrates the sequence of messages for the SubscriptionEnd Test.

Success Criteria

Receipt of a valid Subscribe message by the Event Source.

Receipt of a valid SubscribeResponse message by the Subscriber.

Receipt of one or more wrapped Notifications by the Event Sink.

Receipt of a valid SubscriptionEnd message by the Subscriber (or whomever is indicated by the EndTo EPR).

Conformance

Because this test involves the use of the optional wse:EndTo element there are a number of failure cases that fall within the boundaries of conforming behavior.

A conforming Subscriber/Event Sink MAY NOT be capable of implementing this test due to its inability to support the wse:EndTo element or the SubscriptionEnd message.

A conforming Event Source MAY respond to the initial Subscribe request with a wse:EndToNotSupported fault.

Filter Test - XPath 1.0

This test verifies the ability of the Event Source/Subscription Manager to correctly implement XPath 1.0 filters. The initial Subscribe request has the following features:

expiration time chosen by Event Source/Subscription Manager

no EndTo EPR

Filter in dialect 'http://www.w3.org/2010/08/ws-evt/Dialects/XPath10' that selects those events that apply to the animal named 'Kerry': //*[local-name()='Name']/node()='Kerry'

unwrapped notifications

Sequence

The messaging sequence for this test is identical to that of the Basic Test. The difference between this test and the Basic Test is that only Notifications applying to the animal named 'Kerry' are received by the Event Sink.

Success Criteria

Receipt of a valid Subscribe message by the Event Source.

Receipt of a valid SubscribeResponse message by Subscriber.

Receipt of one or more unwrapped Notifications for the animal named 'Kerry' by the Event Sink.

Receipt of a valid Unsubscribe message by the Subscription Manager.

Receipt of a valid UnsubscribeResponse message by the Subscriber.

Conformance

Because this test involves the use of the optional wse:Filter element there are a number of failure cases that fall within the boundaries of conforming behavior.

A conforming Subscriber/Event Sink MAY NOT be capable of implementing this test due to its inability to support the wse:Filter element or the XPath 1.0 dialect.

A conforming Event Source MAY respond to the initial Subscribe request with either a wse:FilteringNotSupported fault or a wse:FilteringRequestedUnavailable fault.

Filter Test - XPath 2.0

This test verifies the ability of the Event Source/Subscription Manager to correctly implement XPath 2.0 filters. The initial Subscribe request has the following features:

expiration time chosen by Event Source/Subscription Manager

no EndTo EPR

Filter in dialect 'http://www.w3.org/2010/08/ws-evt/Dialects/XPath20' that selects those events that apply to the animal named 'Oscar': //*[local-name()='Name']/node()='Oscar'

unwrapped notifications

Sequence

Success Criteria

Receipt of a valid Subscribe message by the Event Source.

Receipt of a valid SubscribeResponse message by Subscriber.

Receipt of one or more unwrapped Notifications for the animal named 'Oscar' by the Event Sink.

Receipt of a valid Unsubscribe message by the Subscription Manager.

Receipt of a valid UnsubscribeResponse message by the Subscriber.

Conformance

Because this test involves the use of the optional wse:Filter element there are a number of failure cases that fall within the boundaries of conforming behavior.

A conforming Subscriber/Event Sink MAY NOT be capable of implementing this test due to its inability to support the wse:Filter element or the XPath 2.0 dialect.

A conforming Event Source MAY respond to the initial Subscribe request with either a wse:FilteringNotSupported fault or a wse:FilteringRequestedUnavailable fault.

Non-Addressable Event Sink Test

This test verifies the ability to subscribe and receive notifications in an environment in which the Event Sink cannot accept connections from systems outside its network (i.e. the Event Sink is non-addressable). The facilities described by WS-MakeConnection are used by the Event Sink to poll for Notifications from the Event Source.

The initial Subscribe request has the following features:

expiration time chose by Event Source/Subscription Manager

no EndTo EPR

no Filters

unwrapped notifications

the value of wse:Delivery/wse:NotifyTo/wsa:Address is an instance of the MakeConnection anonymous URI (e.g. http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000).

Sequence

The following diagram illustrates the sequence of messages for the Non-Addressable Event Sink Test.

Note that the MakeConnection requests that follow both the Subscribe and the Unsubscribe requests are optional. It may happen that the SubscribeResponse and UnsubscribeResponse are both transmitted on the back-channel of their corresponding requests.

Success Criteria

Receipt of a valid Subscribe message by the Event Source.

Receipt of a valid SubscribeResponse message by Subscriber.

Receipt of one or more unwrapped Notifications by the Event Sink.

Receipt of a valid Unsubscribe message by the Subscription Manager.

Receipt of a valid UnsubscribeResponse message by the Subscriber.

Because this test involves the use of WS-MakeConnection there are a number of failure cases that fall within the boundaries of conforming behavior.

A conforming Subscriber/Event Sink MAY NOT be capable of implementing this test due to its inability to support WS-MakeConnection.

A conforming Event Source MAY respond to the initial Subscribe request with a wse:UnusableEPR fault. However, because WS-Eventing does not require Event Sources to validate the NotifyTo EPR at subscribe-time, it MAY be that the Subscribe request succeeds (although the SubscribeResponse is never delivered to the Subscriber) but Notifications are simply not delivered to the Event Sink.

Because Event Sinks and Subscription Managers are not required to implment WS-MakeConnection, the MakeConnection requests MAY elicit a wsa:ActionNotSupported fault response or some other, unspecified behavior.

WS-Transfer/WS-Fragment Tests

This section describes the tests for WS-Transfer and WS-Fragment.

Create Test

This test will verifies the ability to create a new Animal/Tag in the service. The Create message will contain the initial representation of the new Animal/Tag.

Sequence

...

Success Criteria

Receipt of a valid Create message by the service.

Receipt of a valid CreateResponse message by the client.

Conformance

A conforming service MUST respond to the Create request with a CreateResponse message.

Get Test

This test verifies the ability of a client to retrieve the current representation of an Animal/Tag. The endpoint to which this test is executed against may be any valid endpoint created during the Create test or returned from any other test described in this document as long as it refers to an Animal resource. The use of WS-MetadataExchange is recommeneded to ensure that the endpoint supports WS-Transfer.

Sequence

...

Success Criteria

Receipt of a valid Get message by the service.

Receipt of a valid GetResponse message by the service.

Conformance

A conforming service MUST respond to the Get request with a GetResponse message containing the current representation of the Animal/Tag.

Fragment Get Test

This test verifies the ability of a client to retrieve a subset of the current representation of an Animal/Tag. The endpoint to which this test is executed against may be any valid endpoint created during the Create test or returned from any other test described in this document as long as it refers to an Animal resource. The use of WS-MetadataExchange is recommeneded to ensure that the endpoint supports WS-Transfer.

Sequence

...

Success Criteria

Receipt of a valid Get message containing the WS-Fragment Dialect IRI by the service.

Receipt of a valid GetResponse message by the service.

Conformance

The Get request uses the WS-Fragment Dialect IRI and asks for a subset of the representation using XPath 1.0. A conforming service MUST either respond with a wst:UnknownDialect fault or return just the requested data.

Put Test

This test verifies the ability of a client to update the current representation of an Animal/Tag. The endpoint to which this test is executed against may be any valid endpoint created during the Create test or returned from any other test described in this document as long as it refers to an Animal resource. The use of WS-MetadataExchange is recommeneded to ensure that the endpoint supports WS-Transfer.

Sequence

...

Success Criteria

Receipt of a valid Put message by the service.

Receipt of a valid PutResponse message by the client.

Conformance

A conforming service MUST respond to the Put request with a PutResponse message.

Fragment Put Test

This test verifies the ability of a client to update a portion of the current representation of an Animal/Tag. The endpoint to which this test is executed against may be any valid endpoint created during the Create test or returned from any other test described in this document as long as it refers to an Animal resource. The use of WS-MetadataExchange is recommeneded to ensure that the endpoint supports WS-Transfer.

Sequence

In this test the client issues a series of Put requests to update the representation of an Animal/Tag. After each request the client will issue a Get to verify that the update was successful.

Success Criteria

Receipt of a valid Put message using the WS-Fragment Dialect IRI by the service.

Receipt of a valid PutResponse message by the client.

Receipt of a valid Get message by the service.

Receipt of a valid GetResponse message by the client.

Conformance

A conforming service MUST respond to the Put request with either a wst:UnknownDialect fault or return a PutResponse message. A conforming service MUST also respond to the subsequent Get request with a GetResponse message containing the new representation of the Animal/Tag - or with no change if the Put was rejected.

Variations

Except when noted, the following variations use this Animal representation as an example guide for what each variation is expected to produce:

<sce:Animal xmlns:sce="http://www.w3.org/2002/ws/ra/test/scenario"> <sce:ID> ... </sce:ID> <sce:Name> ... </sce:Name> <sce:Birthdate> ... </sce:Birthdate> <sce:Gender> ... </sce:Gender> <sce:Family> ... </sce:Family> <sce:Genus> ... </sce:Genus> <sce:Species> ... </sce:Species> <sce:CurrentLocation> ... </sce:CurrentLocation> <sce:History> <sce:Entry> ... </sce:Entry> <sce:Entry Date="..."> ... </sce:Entry> </sce:History> </sce:Animal>

The following Fragment Put expressions/values are tested:

Mode: Add Expression: / Value: <sce:Animal> ... </sce:Animal> Result: a fault is generated

Mode: Replace Expression: / Value: <sce:Animal> ... </sce:Animal> Result: entire Animal is replaced

Mode: Add Expression: //*[local-name()='History']/*[1] Value: Date="..." Result: first History/Entry has a Date attribute added

Mode: Add Expression: //*[local-name()='History']/*[2] Value: Date="..." Result: a fault is generated

Mode: Replace Expression: //*[local-name()='History']/*[2]/@Date Value: Date="..." Result: Date attribute is updated

Mode: Replace Expression: //*[local-name()='History']/*[2]/@Date Value: Who="..." Result: Date attribute is erased and Who attribute is added

Mode: Replace Expression: //*[local-name()='History']/*[1]/@Date Value: Who="..." Result: Who attribute is added to the Entry

Mode: Remove Expression: //*[local-name()='History']/*[2]/@Date Value: - Result: Date attribute is removed

Mode: Add Expression: //*[local-name()='History'] Value: <sce:Entry> ... </sce:Entry> Result: Entry is added to History array History array needs to be empty before test starts

Mode: Add Expression: //*[local-name()='History'] Value: <sce:Entry> ... </sce:Entry> Result: Entry is added to the end of the History array History array needs to have atleast one Entry

Mode: Replace Expression: //*[local-name()='History']/*[local-name()='Entry'] Value: <sce:Entry> ... </sce:Entry> Result: First Entry is replaced History array needs to have one Entry

Mode: Replace Expression: //*[local-name()='History']/*[1] Value: <sce:Entry> ... </sce:Entry> Result: Entry is added to the History array History array needs to be empty before test starts

Mode: InsertAfter Expression: //*[local-name()='History']/*[local-name()='Entry'] Value: <sce:Entry> ... </sce:Entry> Result: Entry is added to the end of the History array

Mode: InsertBefore Expression: //*[local-name()='History']/*[local-name()='Entry'] Value: <sce:Entry> ... </sce:Entry> Result: Entry is added to the start of the History array

Mode: Replace Expression: //*[local-name()='History']/*[local-name()='Entry'] Value: <sce:Entry> ... </sce:Entry> Result: All old Entries are replace by this one Entry

Mode: Replace Expression: //*[local-name()='History']/*[1] Value: <sce:Entry> ... </sce:Entry> Result: First Entry is replaced

Mode: Remove Expression: //*[local-name()='History']/* Value: - Result: All Entry elements are removed History array needs to have one Entry

Mode: Remove Expression: //*[local-name()='History']/* Value: - Result: All Entry elements are removed

Mode: Remove Expression: //*[local-name()='History']/*[1] Value: - Result: Just first Entry is removed

Mode: InsertBefore Expression: //*[local-name()='History']/*[local-name()='Entry'] Value: <sce:Entry> ... </sce:Entry> Result: New Entry is added to History array History array needs to be empty before test starts

Mode: InsertAfter Expression: //*[local-name()='History']/*[local-name()='Entry'] Value: <sce:Entry> ... </sce:Entry> Result: New Entry is added to History array History array needs to be empty before test starts

Delete Test

This test verifies the ability of a client to delete an Animal/Tag. The endpoint to which this test is executed against may be any valid endpoint created during the Create test or returned from any other test described in this document as long as it refers to an Animal resource. The use of WS-MetadataExchange is recommeneded to ensure that the endpoint supports WS-Transfer.

Sequence

...

Success Criteria

Receipt of a valid Delete message by the service.

Receipt of a valid DeleteResponse message by the client.

Conformance

A conforming service MUST respond to the Delete request with a DeleteResponse message.

WS-Enumeration Tests

This section describes the tests for WS-Enumeration.

Basic Test

This test verifies the ability to enumerate instances of a resource using the default behavior. The initial Enumerate request has the following salient features:

NewContext element

The subsequent Enumerate requests have the following salient features:

EnumerationContext element that was provided by the data source

Sequence

The following diagram illustrates the sequence of messages for the Basic Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element and with one item by the data consumer

Receipt of one or more valid Enumerate messages with EnumerationContext element by the data source

Receipt of one or more valid EnumerateResponse messages with one item by the data consumer

Receipt of a valid Enumerate message with EnumerationContext element by the data source

Receipt of a valid EnumerateResponse message with EndOfSequence element by the data consumer

Conformance

A conforming data source MAY NOT be capable of implementing this test due to its inability to return items in response to an Enumerate request that also created a new enumeration.

A conforming data source MAY respond to the initial Enumerate request with a wsen:MaxElementsMustBeZero fault.

New Empty Enumeration Test

This test verifies the ability to create a new enumeration without retrieving any of the data items in the first EnumerateResponse message. The initial Enumerate request has the following salient features:

NewContext element

MaxElements element equal to 0

The subsequent Enumerate requests have the following salient features:

EnumerationContext element that was provided by the data source

Sequence

The messaging sequence for this test is identical to that of the Basic Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element and MaxElements equal to 0 by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element and with no items by the data consumer

Receipt of one or more valid Enumerate messages with EnumerationContext element by the data source

Receipt of one or more valid EnumerateResponse messages with one item by the data consumer

Receipt of a valid Enumerate message with EnumerationContext element by the data source

Receipt of a valid EnumerateResponse message with EndOfSequence element by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the optional wsen:MaxElements element.

Because this test involves only operations and elements that are required to be supported by the data source, there are no allowable failure cases.

Optimized Enumeration Test

This test verifies the ability to enumerate an entire set of instances of a resource with just one Enumerate message. The Enumerate request has the following salient features:

NewContext element

MaxElements element with large value

Sequence

The following diagram illustrates the sequence of messages for the Optimized Enumeration Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element and MaxElements equal to large number by the data source

Receipt of a valid EnumerateResponse message with all Items and EndOfSequence element by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the optional wsen:MaxElements element.

A conforming data source MAY NOT be capable of implementing this test due to its inability to return items in response to an Enumerate request that also created a new enumeration.

A conforming data source MAY respond to the initial Enumerate request with a wsen:MaxElementsMustBeZero fault.

MaxCharacters Test

This test verifies the ability of a data consumer to limit the size of the items returned from an enumeration using the wsen:MaxCharacters element. The initial Enumerate request has the following salient features:

NewContext element

MaxElements element with large value

MaxCharacters element with a value slightly bigger than one returned item

The subsequent Enumerate requests have the following salient features:

EnumerationContext element that was provided by the data source

MaxElements element with a large value

MaxCharacters element with a value slightly bigger than one returned item

Sequence

The messaging sequence for this test is identical to that of the Basic Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element, MaxElements element and MaxCharacters element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element and with one item by the data consumer

Receipt of one or more valid Enumerate messages with EnumerationContext element, MaxElements element and MaxCharacters element by the data source

Receipt of one or more valid EnumerateResponse messages with one item by the data consumer

Receipt of a valid Enumerate message with EnumerationContext element, MaxElements element and MaxCharacters element by the data source

Receipt of a valid EnumerateResponse message with EndOfSequence element by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the optional wsen:MaxElements element or the optional wsen:MaxCharacters element.

Because this test involves only operations and elements that are required to be supported by the data source, there are no allowable failure cases.

MaxTime Test

This test verifies the ability of a data consumer to limit the amount of time it takes for the data source to assemble an EnumerateResponse using the wsen:MaxTime element. The initial Enumerate request has the following salient features:

NewContext element

The second Enumerate request has the following salient features:

EnumerationContext element that was provided by the data source

MaxTime element with a very low value. If a data source is designed such that the MaxTime value will have no impact, for the purposes of testing a data source is to return a wsen:TimesOut fault if the MaxTime value is present with a value less than 5 seconds.

The subsequent Enumerate requests have the following salient features:

EnumerationContext element that was provided by the data source

Sequence

The messaging sequence for this test is identical to that of the Basic Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element and with one item by the data consumer

Receipt of one valid Enumerate message with EnumerationContext element and MaxTime element by the data source

Receipt of valid EnumerateResponse message with zero items and with Items/@Reason equal to http://www.w3.org/2010/08/ws-enu/TimedOut by the data consumer

Receipt of one or more valid Enumerate messages with EnumerationContext element by the data source

Receipt of one or more valid EnumerateResponse messages with one item by the data consumer

Receipt of a valid Enumerate message with EnumerationContext element by the data source

Receipt of a valid EnumerateResponse message with EndOfSequence element by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the optional wsen:MaxTime element.

Because this test involves only operations and elements that are required to be supported by the data source, there are no allowable failure cases.

Duration Expiration Test

This test verifies the correct implementation of the expiration feature on the data source. The initial Enumerate message has the following salient features:

NewContext element

Expires element with a short expiration time as xs:duration

The second Enumerate request has the following salient features:

EnumerationContext element that was provided by the data source

Sequence

The following diagram illustrates the sequence of messages for the Duration Expiration Test. Note that the data source waits until the expiration time has passed before sending the second Enumerate request.

Success Criteria

Receipt of valid Enumerate message with NewContext element and Expires element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element and with one item by the data consumer

Receipt of valid Enumerate message with EnumerationContext element by the data source

Receipt of a wsen:InvalidEnumerationContext fault by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the optional wsen:Expires element with a value of type xs:duration.

A conforming data source MAY NOT be capable of implementing this test due to its inability to grant an expiration time that matches the specified value in the Enumerate request.

A conforming data source MAY respond to the initial Enumerate request with a wsen:UnsupportedExpirationValue fault.

Specific Time Expiration Test

This test verifies the correct implementation of the expiration feature on the data source. The initial Enumerate message has the following salient features:

NewContext element

Expires element with a short expiration time as xs:dateTime

The second Enumerate request has the following salient features:

EnumerationContext element that was provided by the data source

Sequence

The messaging sequence for this test is identical to that of the Duration Expiration Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element and Expires element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element and with one item by the data consumer

Receipt of valid Enumerate message with EnumerationContext element by the data source

Receipt of a wsen:InvalidEnumerationContext fault by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the optional wsen:Expires element with a value of type xs:datetime.

A conforming data source MAY NOT be capable of implementing this test due to its inability to grant an expiration time that matches the specified value in the Enumerate request, or to its inability to support specific expiration time values.

A conforming data source MAY respond to the initial Enumerate request with a wsen:UnsupportedExpirationValue fault or a wsen:UnsupportedExpirationType fault.

Best Effort Expiration Test

This test verifies the correct implementation of the "best effort expiration feature on the data source. The initial Enumerate message has the following salient features:

NewContext element

Expires element with a short expiration time as xs:duration with @BestEffort=true

The second Enumerate request has the following salient features:

EnumerationContext element that was provided by the data source

Sequence

The messaging sequence for this test is identical to that of the Duration Expiration Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element and Expires element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element and with one item by the data consumer

Receipt of valid Enumerate message with EnumerationContext element by the data source

Receipt of a wsen:InvalidEnumerationContext fault by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the optional wsen:Expires element with a value of type xs:duration or with the @BestEffort attribute.

Because this test involves only operations and elements that are required to be supported by the data source, there are no allowable failure cases.

GetStatus Test

This test verifies the ability of a data consumer to get the status of an existing enumeration. The initial Enumerate request has the following salient features:

NewContext element

The GetStatus message has the following salient features:

EnumerationContext element that was provided by the data source

Sequence

The following diagram illustrates the sequence of messages for the GetStatus Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element by the data consumer

Receipt of valid GetStatus message with EnumerationContext element by the data source

Receipt of valid GetStatusResponse message by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the GetStatus operation.

Because this test involves only operations and elements that are required to be supported by the data source, there are no allowable failure cases.

Renew Test

This test verifies the ability of a data consumer to renew an existing enumeration. The initial Enumerate request has the following salient features:

NewContext element

The Renew message has the following salient features:

EnumerationContext element that was provided by the data source

Sequence

The following diagram illustrates the sequence of messages for the Renew Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element by the data consumer

Receipt of valid Renew message with EnumerationContext element by the data source

Receipt of valid RenewResponse message by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the Renew operation.

A conforming data source MAY choose not to renew the enumeration and instead respond to the Renew request with a SOAP 1.1 Server fault or a SOAP 1.2 Receiver fault.

Release Test

This test verifies the ability of a data consumer to release an existing enumeration before its data items have all been retrieved. The initial Enumerate request has the following salient features:

NewContext element

The Release message has the following salient features:

EnumerationContext element that was provided by the data source

Sequence

The following diagram illustrates the sequence of messages for the Release Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element by the data consumer

Receipt of valid Release message with EnumerationContext element by the data source

Receipt of valid ReleaseResponse message by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the Release operation.

Because this test involves only operations and elements that are required to be supported by the data source, there are no allowable failure cases.

EnumerationEnd Test

This test verifies the ability of a data source to send a notification to a data consumer if it terminates the enumeration unexpectedly. The initial Enumerate request has the following salient features:

NewContext element

EndTo element containing an EPR for the data consumer

Note: this test requires the client to include an additional element in the sce:Scenario header:

<sce:EndTime> xs:duration | xs:dateTime </sce:EndTime>

The duration/time specified by this element indicates when the data source is to "unexceptedly" terminate the enumeration, thus causes the EnumerationEnd message to be sent. The value specified in this element must be less than the expires time specified in the Enumerate request message used to create the enumeration.

Sequence

The following diagram illustrates the sequence of messages for the EnumerationEnd Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element and EndTo element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element by the data consumer

Receipt of valid EnumerationEnd message by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the optional wsen:EndTo element or the EnumerationEndPortType portType.

A conforming data source MAY NOT be capable of implementing this test due to its inability to support the use of the EndTo EPR.

A conforming data source MAY respond to the initial Enumerate request with a wsen:EndToNotSupported fault.

A conforming data source MAY respond to the initial Enumerate request with a wsen:UnusableEPR fault if it checks the validity of the EndTo EPR and detects a problem.

Filter Test - XPath 1.0

This test verifies the ability of the data source to correctly implement XPath 1.0 filters. The initial Enumerate request has the following salient features:

NewContext element

Filter element with @Dialect equal to 'http://www.w3.org/2010/08/ws-enu/Dialects/XPath10' (actual filter expression TBD)

The subsequent Enumerate requests have the following salient features:

EnumerationContext element that was provided by the data source

Sequence

The messaging sequence for this test is identical to that of the Basic Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element and Filter element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element and with one item by the data consumer

Receipt of one or more valid Enumerate messages with EnumerationContext element by the data source

Receipt of one or more valid EnumerateResponse messages with one item by the data consumer

Receipt of a valid Enumerate message with EnumerationContext element by the data source

Receipt of a valid EnumerateResponse message with EndOfSequence element by the data consumer

Conformance

A conforming data consumer MAY NOT be capable of implementing this test due to its inability to support the optional wsen:Filter element or the @Dialect 'http://www.w3.org/2010/08/ws-enu/Dialects/XPath10'.

A conforming data source MAY NOT be capable of implementing this test due to its inability to support filtering, to process the filter dialect 'http://www.w3.org/2010/08/ws-enu/Dialects/XPath10', or to process the filter content.

A conforming data source MAY respond to the initial Enumerate request with a wsen:FilteringNotSupported fault, a wsen:FilterDialectRequestedUnavailable fault, or a wsen:CannotProcessFilter fault.

A conforming data source MAY respond to the initial Enumerate request with a wsen:EmptyFilter fault if it detects that the filter will never evaluate to true for the lifetime of the enumeration.

Filter Test - XPath 2.0

This test verifies the ability of the data source to correctly implement XPath 2.0 filters. The initial Enumerate request has the following salient features:

NewContext element

Filter element with @Dialect equal to 'http://www.w3.org/2010/08/ws-enu/Dialects/XPath20' (actual filter expression TBD)

The subsequent Enumerate requests have the following salient features:

EnumerationContext element that was provided by the data source

Sequence

The messaging sequence for this test is identical to that of the Basic Test.

Success Criteria

Receipt of valid Enumerate message with NewContext element and Filter element by the data source

Receipt of a valid EnumerateResponse message with EnumerationContext element and with one item by the data consumer

Receipt of one or more valid Enumerate messages with EnumerationContext element by the data source

Receipt of one or more valid EnumerateResponse messages with one item by the data consumer

Receipt of a valid Enumerate message with EnumerationContext element by the data source

Receipt of a valid EnumerateResponse message with EndOfSequence element by the data consumer

Conformance

A conforming data source MAY respond to the initial Enumerate request with a wsen:FilteringNotSupported fault, a wsen:FilterDialectRequestedUnavailable fault, or a wsen:CannotProcessFilter fault.

A conforming data source MAY respond to the initial Enumerate request with a wsen:EmptyFilter fault if it detects that the filter will never evaluate to true for the lifetime of the enumeration.

WS-SOAP Assertions & WS-Event Descriptions

While this working group will not explicitly test the use of WS-Policy, this test scenario allows for the inclusion of the WS-SA and WS-EVD policy assertions to appear in the WSDL of the Tracker Service. In doing this the scenario is verifying that the assertions can successfully be included as part of the WSDL/Policy of a service.

WSDL Event Source WSDL

TBD

Notification WSDL

Available here: http://www.w3.org/2002/ws/ra/test/scenario/scenarioSink.wsdl

EventDescriptions

Available here: http://www.w3.org/2002/ws/ra/test/scenario/scenarioSource.evd

Schemas

TBD

Acknowledgements

This specification has been developed as a result of joint work with many individuals and teams, including: Alessio Soldano (Red Hat), Ashok Malhotra (Oracle Corp.), Asir Vedamuthu (Microsoft Corp.), Bob Freund (Hitachi, Ltd.), Bob Natale (MITRE Corp.), David Snelling (Fujitsu, Ltd.), Doug Davis (IBM), Fred Maciel (Hitachi, Ltd.), Geoff Bullen (Microsoft Corp.), Gilbert Pilz (Oracle Corp.), Greg Carpenter (Microsoft Corp.), Jeff Mischkinsky (Oracle Corp.), Katy Warr (IBM), Li Li (Avaya Communications), Mark Little (Red Hat), Martin Chapman (Oracle Corp.), Paul Fremantle (WSO2), Paul Nolan (IBM), Prasad Yendluri (Software AG), Ram Jeyaraman (Microsoft Corp.), Sreedhara Narayanaswamy (CA), Sumeet Vij (Software AG), Tom Rutt (Fujitsu, Ltd.), Vikas Varma (Software AG), Wu Chou (Avaya Communications), Yves Lafon (W3C/ERCIM).

References Normative References Key words for use in RFCs to Indicate Requirement Levels , S. Bradner, Author. Internet Engineering Task Force, March 1997. W3C Note, "Simple Object Access Protocol (SOAP) 1.1" , D. Box, et al, Editors. World Wide Web Consortium (W3C), 8 May 2000. W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework" , M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielson, Editors. World Wide Web Consortium (W3C), 27 April 2007. W3C Recommendation, "Web Services Addressing 1.0 (WS-Addressing)" , M. Gudgin, M. Hadley, T. Rogers, Editors. World Wide Web Consortium (W3C), 9 May 2006. W3C Working Group Draft, "Web Services Enumeration (WS-Enumeration) 1.1" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. W3C Working Group Draft, "Web Services Event Descriptions (WS-EventDescriptions) 1.0" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. W3C Working Group Draft, "Web Services Eventing (WS-Eventing) 1.1" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. W3C Working Group Draft, "Web Services Fragment (WS-Fragment) 1.0" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. W3C Working Group Draft, "Web Services Metadata Exchange (WS-MetadataExchange) 1.1" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. W3C Working Group Draft, "Web Services SOAP Assertions (WS-SOAPAssertions) 1.0" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. W3C Working Group Draft, "Web Services Transfer (WS-Transfer) 1.1" , D. Davis, et al., Editors. World Wide Web Consortium (W3C), 15 September 2009. W3C Note, "Web Services Description Language (WSDL) 1.1" , E. Christensen, et al., Editors. World Wide Web Consortium (W3C), 15 March 2001 W3C Recommendation, "XML Schema Part 1: Structures (Second Edition)" , H. Thompson, et al., Editors. World Wide Web Consortium (W3C), 28 October 2004. W3C Recommendation, "XML Schema Part 2: Datatypes (Second Edition)" , P. Biron, A. Malhotra, Editors. World Wide Web Consortium (W3C), 28 October 2004. XML Schema

A normative copy of the XML Schema , description for this specification can be retrieved from the following address:

http://www.w3.org/2002/ws/ra/test/scenario/scenario.xsd

A non-normative copy of the XML schema is listed below for convenience.

<xs:schema targetNamespace='http://www.w3.org/2002/ws/ra/test/scenario' xmlns:tns='http://www.w3.org/2002/ws/ra/test/scenario' xmlns:xs='http://www.w3.org/2001/XMLSchema' elementFormDefault='qualified' blockDefault='#all' > <xs:complexType name='emptyElementType'> <xs:sequence> <xs:any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> </xs:sequence> <xs:anyAttribute namespace='##other' processContents='lax'/> </xs:complexType> <xs:element name='SOAP11' type='tns:emptyElementType'/> <xs:element name='SOAP12' type='tns:emptyElementType'/> </xs:schema> Change Log

Data	Author	Description
2010/10/26	GP	Initial revision
2010/10/27	GP	Fleshed out Basic, Wrapped, and Expiration tests; added sequence diagrams. Added stubs for Renew and Non-Addressable Event Sink tests.
2010/10/28	GP	Editorial fixes. Changed animal names in honor of the Irish light-bellied Brent Geese tracked by the WWT (http://www.wwt.org.uk/).
2010/10/30	GP	Added 34Conformance34 sections to each test that describe any allowable failures. Added sequence diagrams to Renew Test, SubscriptionEnd Test, and Non-Addressable Event Sink Test.
2011/01/09	DD	Add a history section to each animal so we can track medical history or just make notes about the animal. Really, we need an array and something with an attribute to test frag stuf
2011/01/14	NB	Added initial Enum section
2011/02/02	DD	Moved from edcopies dir to test dir
2011/02/02	DD	Updated frag xpath to not need prefix namespace mapping
2011/02/04	DD	Add the sce:Scenario header and the sce:EndTime element
2011/03/22	DD	Updates from Nathan
2011/04/07	DD	Update namespaces to CR version - http://www.w3.org/2011/03/...