Web Services Resource Access (WS-RA) Working Group Charter

The mission of the Web Services Resource Access Working Group, part of the Web Services Activity, is to produce W3C Recommendations for a set of Web Services specifications by refining the WS-Transfer, WS-ResourceTransfer, WS-Enumeration, WS-MetadataExchange and WS-Eventing Member Submissions (referred to in this charter as "the submitted specifications"), addressing existing issues in those specifications, implementation experience and interoperability feedback from implementers and considering composition with other Web services standards.

The submitted specifications define SOAP-based mechanisms for interacting with the XML representation behind a resource-oriented Web Service, accessing metadata related to that service, as well as a mechanism to subscribe to events related to that resource. WS-Transfer defines the basic Create, Read, Update, Delete (CRUD) operations against resource-oriented Web Service data. WS-ResourceTransfer enhances these operations, through the extensibility points of WS-Transfer, with the addition of fragment and batched access. WS-Enumeration provides a protocol that allows a resource to provide a context, called an enumeration context, to a consumer that represents a logical cursor through a sequence of data items. WS-Eventing allows interested parties to subscribe to a series of notifications from a resource oriented Web Service. WS-MetadataExchange defines a mechanism by which metadata about a Web Service can be retrieved. When used in conjunction with WS-Transfer, WS-ResourceTransfer and WS-Enumeration, this metadata can be accessed and managed just like any other Web Service resource.

These specifications are relevant to other standardization efforts that rely on resource access and event subscription mechanisms. To meet these needs, Web Services Resource Access Working Group should complete its work in a timely fashion.

Join the Web Services Resource Access Working Group.

End date 30 June 2012
Confidentiality Proceedings are public
Initial Chairs Bob Freund
Initial Team Contacts
(FTE %: 30 )
Yves Lafon
Usual Meeting Schedule See Meetings


The Web Services Resource Access Working Group is chartered to standardize a general mechanism for accessing and updating the XML representation of a resource-oriented Web Service and metadata of a Web Service, as well as a mechanism to subscribe to events from a Web Service. The following list of features is intended to focus the work of the Working Group and ensure its timely completion:

  1. The definition of basic Create, Read, Update, Delete (CRUD) operations that provide capabilities to create, read, update and delete a Web Service’s XML representation and the binding of these operations to SOAP.
  2. A mechanism to allow a requester to retrieve metadata, or references to metadata, related to a Web Service and a mechanism to allow embedding of such metadata, or references to such metadata, in an Endpoint Reference (EPR). The defined capability must provide for retrieval and embedding of specific items of metadata such as WSDL, XML Schema and WS-Policy. The referencing of metadata must allow for both EPR or URL style references.
  3. The definition of Web service operations (e.g. Enumerate, Pull, etc…) to enable a consumer to request and manage an enumeration context, and retrieve data items from an enumeration context for a data source. These operations must define details of SOAP messages for the request and response as well as one or more filter dialects to select the data that would be sent to the consumer. The ability to work efficiently with large datasets is important.
  4. The definition of Web Services operations (e.g. Subscribe, Unsubscribe, etc…) to create and manage subscriptions to events that are delivered via Web Services.
    1. The definition of one or more filter dialects, such as XPath, that can be used in subscriptions to indicate interest in messages with specific content.
    2. Mechanisms to allow a subscriber to specify the means by which an event is delivered and the definition of a push-based delivery mode.
  5. A mechanism by which a Web Service can advertise, through its metadata, such as WSDL and WS-Policy, the capabilities it supports from among the features defined by the Web Service Resource Access specifications.

In addition to the points listed above, the Working Group may address the following optimization-related topics:

  1. A mechanism by which a fragment of the XML representation of a resource can be identified for the purpose of accessing, updating or deleting it.
    1. The definition of one or more common expression dialects to identify these fragments.
  2. The capabilities in listed above should be designed so that they can be implemented efficiently. For example, it may be desirable to allow the batching of similar requests into a single request.

The Web Services Resource Access Working Group will take as its starting point the Member Submission versions of WS-Transfer, WS-ResourceTransfer, WS-Enumeration, WS-Eventing and WS-MetadataExchange. In order to avoid disrupting the interoperability of existing implementations, WS-MetadataExchange, WS-Transfer, WS-Eventing and WS-Enumeration should remain compatible with protocols and formats that depend on them, and offer a smooth migration path from the submission to the standard.

The Working Group will work to minimize overlap and maximize composability with other Web Services specifications.

The specification should be based on W3C Recommendations (SOAP Version 1.2, WS-Addressing 1.0, WSDL2.0, WS-Policy 1.5) and aligned with ISO 29361:2008 (WS-I BP 1.1). However, the Working Group should also consider conformance to the forthcoming profiles WS-I is finalizing assuming they achieve WS-I "Final Material" status before the Working Group completes its deliverables.

Success Criteria

The Web Services Resource Access Working Group will define the specifics of their exit criteria before Last Call. The Working Group is expected to demonstrate at least two interoperable implementations of each deliverable during the Call for Implementations step of the set of features not marked as "at risk" for each Recommendation specification.


New publications

  • W3C Recommendations for the output specifications of this Working Group. The Working Group may organize the structure of the specifications into one or more documents.
  • A test suite intended to promote implementation of the Candidate Recommendation, and to assess interoperability between these implementations.
  • Optionally, a primer that includes guidance on the use of the specifications.
  • Optionally, a new charter for follow-on work on these specifications per the World Wide Web Consortium Process Document.


Note: The group will document significant changes from this initial schedule on the group home page.
Specification FPWD LC CR PR Rec
WS-Transfer January 2008 April 2009 July 2009 December 2009 February 2010
WS-ResourceTransfer January 2008 April 2009 July 2009 December 2009 February 2010
WS-Enumeration January 2008 April 2009 July 2009 December 2009 February 2010
WS-MetadataExchange January 2008 April 2009 July 2009 December 2009 February 2010
WS-Eventing January 2008 April 2009 July 2009 December 2009 February 2010

Timeline View Summary

This timeline should be revised, if needed, when the WG is chartered.

  • November 2008: Working Group created.
  • January 2009: Publish First public drafts for output specifications.
  • January 2009: First face-to-face meeting.
  • April 2009: Second face-to-face meeting. Publish Last Call drafts for output specifications.
  • June 2009: Third face-to-face meeting.
  • July 2009: Candidate Recommendation drafts for output specifications; Fourth face-to-face meeting.
  • September 2009: Fifth face-to-face meeting.
  • December 2009: Publish Proposed Recommendation drafts for output specifications.
  • February 2010 W3C Recommendations for output specifications.
  • February 2010 - June 2010: Post Recommendation work, next steps considerations

Note that all specifications might not be published at the same time, introducing shifts in this timeline.


W3C Groups

The Web Services Resource Access Working Group should coordinate its efforts with other Working Groups involved in the Web Services Activity, like the XML Protocol Working Group and the Web Services Policy Working Group.

As part of the Web Services Activity, the Web Services Resource Access Working Group Chair and Team Contact will be represented in the Web Services Coordination Group.

The W3C TAG has expressed interest in this area by means of a TAG White Paper authored by Noah Mendelsohn.

External Groups

The following organizations have groups that may utilize, or compose with, the Web Services Resource Access specifications:

Organization for the Advancement of Structured Information Standards
OASIS is a not-for-profit, international consortium that drives the development, convergence and adoption of e-business standards.
Distributed Management Task Force, Inc.
The DMTF is an industry organization focused on the development, adoption and promotion of interoperable management initiatives and standards.
Web Service Interoperability
The Web Services Interoperability Organization is an open industry organization chartered to establish Best Practices for Web services interoperability, for selected groups of Web services standards, across platforms, operating systems and programming languages.


Effective participation is expected to consume one or two workdays per week for each Working Group participant; two or more days per week for editors. The Chair shall ensure that the criteria for Good Standing are understood and followed.

To be successful, we expect the Web Services Resource Access Working Group to have 10 or more active participants for its duration.

Participants are expected to carry out their assignments in a timely fashion, attend most meetings, and to remain familiar with group documents and mailing list discussion (W3C Process Document, section Active participation will help ensure rapid progress.


The Web Services Resource Access Working Group will have distributed and face-to-face meetings.

At least up until the Last Call period ends a Working Group distributed meeting will be held as needed. Thereafter, a Working Group distributed meeting will be held every week. When necessary to meet agreed-upon deadlines, distributed meetings may be held twice a week. Face-to-face meetings are expected to occur as needed.

The Web Services Resource Access Working Group may adjust the timing and duration of meetings to address the workload and assure that the goals and schedule of this charter are achieved.


This group primarily conducts its work on the public mailing list public-ws-resource-access@w3.org. A Member-only mailing list member-ws-resource-access@w3.org is also available for administrative purposes.

Information about the group (deliverables, participants, face-to-face meetings, teleconferences, etc.) is available from the Web Services Resource Access Working Group home page.

Decision Policy

As explained in the Process Document (section 3.3), this group will seek to make decisions when there is consensus. When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should record a decision (possibly after a formal vote) and any objections, and move on.

This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.

About this Charter

This charter for the Web Services Resource Access Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

$Date: 2011/08/01 10:04:39 $