One of the requirements for the development of Web services is the
ability to describe the interface, the boundary across which applications
(Web services user agents and Web services) communicate. Applications can
then interoperate using this interface.

The Web Services Description Working Group, part of the Web Services Activity, is
chartered to design the following components of the interface:

The language proposed must support the kind of extensibility
actually seen on the Web: disparity of document formats and
protocols used to communicate, mixing of XML vocabularies using
XML namespaces, development of solutions in a distributed
environment without a central authority, etc. In particular, it
must support distributed extensibility.

The remainder of this section describes the requirements and
deliverables in more detail.

The Working Group shall start by developing a requirements document
detailing and refining the scope of its work, which is the scope of the WSDL 1.1
specification. It will then proceed by evaluating the technical
solutions offered by WSDL 1.1.

If in this process the Working Group finds solutions that are agreed to
be improvements over solutions suggested by WSDL 1.1, those improved
solutions should be used. However, the Working Group should not make
arbitrary changes, i.e. without technical reasons, and it should be easy to
convert a WSDL 1.1 description into the new format designed.

In addition to the specification of a description language, the Working
Group will produce a primer in order to help novices familiarize themselves
with this technology.

A test suite will be developed by the Working Group in order to assess
advancement to Proposed Recommendation stage and to promote
interoperability. The Working Group is expected to demonstrate two
interoperable implementations during the Candidate Recommendation phase.
Conformance requirements must be clearly stated in the specification
produced.

Simplicity is a key element in making distributed systems easy to
understand, implement, maintain, and evolve. Although simplicity can only
be measured in relative terms, the Working Group must ensure that the
complexity of any solution produced is comparable to that of other current
and widespread Web solutions. Note that simplicity should not be confused
with being easy to understand.

It is believed that limiting its scope to exclude bindings to
existing programming languages will put the Working Group in a
better position to
achieve its goal of producing a simple mechanism for describing the
functionality made available by an application to communicating peers.

Another important aspect of simplicity is ease of deployment. The
Working Group will look at various ways of deploying the Web services
descriptions in a manner that is compatible with the existing Web
infrastructure (see the relationship with other
external groups).

Web services are modeled as interfaces between applications on the World
Wide Web. In order to make use of a Web service, one needs to know what
information is expected and in what form.

Therefore, the interface needs to be explained for use by remote
parties. The structure of the messages accepted and/or generated needs to be
described.

The Working Group will define a description language expressed in
XML. The description language must describe the messages available via
the interface, accepted and generated by the Web service. The
language must also describe the error messages generated, if any.

The data exchanged is usually typed and structured. This increases
interoperability by having applications agreeing on semantics and also
provides some level of error detection.

It is expected that developers will want to use different mechanisms for
describing data types and structures, depending on the purpose of the Web
service. The Working Group should allow different mechanisms, and must
define one based on XML Schema. The Working Group
will also take into account the encoding work going on in the XML Protocol Working Group, and will make sure
that SOAP Version 1.2's extensibility
mechanism can be expressed.

The description language designed will be used both by applications in
order to automatically communicate between each other as well as by
programmers developing Web services themselves. The language should
therefore provide, in addition to the raw XML definition of the interface,
human-readable comment capabilities to allow both applications and
developers to make use of them.

Developers are likely to want to extend the functionality of an existing
Web service. The Working Group will look into extending interface
descriptions in a decentralized fashion, i.e. without priori agreement with
the original interface designers.

Interacting using an interface can be done in different ways. Some Web
services may accept an incoming message and return a response, others may
only generate messages, etc.

The Working Group will define a mechanism which will allow a Web service
to describe the following set of operations: one-way messages (to and from
the service described), request-response and solicit-response, as described
in WSDL
1.1's port types.

The information exchanged to and from a Web service can be carried in a
large number of different ways. The action of carrying some XML-based
communication in an underlying protocol is called, in the XML Protocol jargon, a
binding.

The description language defined should therefore describe how to reach
the Web Service in a form which is orthogonal to its message exchange
patterns and its messages.

It is expected that in the near-term future, Web services will be
accessed largely through SOAP
Version 1.2 (the XML-based protocol produced by the XML Protocol Working Group)
carried over HTTP/1.1, or by means of simple HTTP/1.1 GET and POST
requests. The Working Group will describe the following bindings:

SOAP Version 1.2; SOAP can be used over a variety of underlying
protocols; the Working Group will provide a concrete SOAP Version 1.2
over HTTP binding.

HTTP/1.1 GET and POST requests.

The Working Group will also ensure that other SOAP bindings can be
described.

The Semantic Web aims at transforming
the Web into a completely machine-processable information
space. Web services are aiming at enabling automated distributed
computing on the World Wide Web. The work of this Working Group is
essentially the provision of an ontology for Web services.

One of the tools used by Semantic Web-enabled technologies is
RDF. The Working Group will provide a mapping
to RDF so that the information described can be easily merged with
that of other applications. This mapping will be developed with
the help of the RDF Interest
Group.

The area of Web services is very broad as it includes
everything between a simple remote procedure call using an
XML-based protocol to a sequence of N different
services interacting in order to provide very advanced
functionalities (e.g. a travel reservation service making use of
individual services).

It is therefore important to clearly limit the scope of the Working
Group.

This section describes out-of-scope work items. In general, the Working
Group will also consider items out of scope that are being addressed as
part of other W3C Activities,
and it will reuse existing specifications wherever possible, including XML Namespaces and XML
Schemas, Parts One and Two.

Web services are composed of interfaces to applications, which can be
written in different programming languages. The purpose of the Working
Group is to provide a framework that supports a wide variety of
applications and programming languages, and is not geared towards any
programming language. Given the wide variety of programming languages, the
Working Group should not define mappings to any programming languages.

Several individual Web services can be composed to provide more complex
functionalities. The goal of the Web Services Description Working Group is
to describe individual Web services.

Although the Working Group needs to ensure Web services descriptions can
be referenced unambiguously and that the language designed does not
preclude the description of the composition of individual services, the way
two or more services could be composed is considered out of scope.

XML and XML derived activities have become a strategic technology in W3C
and elsewhere. Each deliverable of any Working Group must satisfy the
dependencies from other W3C Working Groups before it can advance to
Candidate Recommendation.

The Web
Services Architecture Working Group is chartered to come up with a
document describing the architecture of Web services. The Working Group
will take this document into account while designing the description
language in order to make sure that Web services can be deployed in an
optimal way, as recommended by the Web Services Architecture Working
Group.

It is expected that other Working Groups will be formed to deal with
different aspects of the Web services architecture. The Working Group
will closely coordinate its work with any other Working Group formed
within the Web Services Activity and generally in the Web services
area.

The typing of the messages must be possible using XML Schema. While no
dependencies other than the one with the XML Schema Working Group are
presently identified, the Web Services Description Working Group should
be prepared to coordinate with the XML Activity as necessary.

The ebXML initiative was
a joint activity of UN/CEFACT (the United Nations
body responsible for UN/EDIFACT)
and OASIS
(Organization for the Advancement of Structured Information
Standards). Their charter was to develop an XML-based
infrastructure for electronic commerce, with a particular
focus on making connections between EDI and XML. While the
original ebXML initiative's charter ended in May of 2001, the
work transitioned to the respective sponsoring organizations
(OASIS and UN/CEFACT) under the auspices of an MOU signed by
the two in May of 2001.

The Working Group will attempt to liaise with the Global Grid Forum.
The Global Grid Forum is a community-initiated forum of individual
researchers and practitioners working on distributed computing
technologies.

The Working Group will attempt to liaise with work going on at OMG.
OMG is a consortium that produces and maintains computer industry
specifications for interoperable enterprise applications and which
has experience in distributed, object-based systems interface
description (CORBA, IDL).

To join the Web Services Description Working Group, please follow the instructions of section
4.2.3 of the Process Document, sending email to the
Working Group Chair and the W3C Team contact. The nomination must
include explicit agreement to this charter, including its goals, an
IPR disclosure and the level of effort required
of the representative.

Each Member organization may have at most two participants in
the Working Group. Only Working Group participants may engage in
formal votes on substantive issues. When a formal vote is
required, each Member organization or group of related Members is
allowed one vote, even though the Member may have several
participants in the Working Group.

The W3C Team is expected to have at most two participants in
the Working Group (including the Team contact). When a formal vote
is required, the Team is allowed one vote.

Membership is also open to invited experts from the
community, selected by the Chair in order to balance the technical
experience of the group.

Each participant should expect to spend one day per week on
work for this Working Group.

The Working Group has a home page that
records the history of the group, provides access to the archives, meeting
minutes, updated schedule of deliverables, membership list, and relevant
documents and resources. The page is available to the public and should
be maintained by the Chair in collaboration with the W3C Team contact.

A one- to two-hour Working Group distributed meeting will be held every
week. When necessary to meet agreed-upon deadlines, distributed meetings
may be held twice a week.

The Working Group may schedule face-to-face meetings in a manner that
maximizes co-location with events that Working Group members would be
attending anyway.

Participation in meetings (distributed or face-to-face) is
limited to participants in good standing and individuals invited
at the discretion of the Chair to specific meetings.

Decisions taken in meetings must be announced on the Working Group
mailing list. Observers may take part in decision-making at the discretion
of the Chair.

Meeting records must include attendance, the results of group decisions,
and action items. They must be made publicly available except for
non-technical issues that do not directly affect the output of the Working
Group. The Chair will decide which issues are not made public.

The W3C Team expects to dedicate the time of the services of one Team Contact, full-time,
for the 2-year duration of the Working Group. Philippe
Le Hégaret will provide this effort with the help of a new
engineer.

W3C promotes an open working environment. Whenever possible, technical
decisions should be made unencumbered by intellectual property right (IPR)
claims. W3C's policy for intellectual property is set out in section
2.2 of the W3C Process document.

Members of the Working Group are expected to disclose any intellectual
property they have in the area. This WG will work on a
royalty-free
basis, as defined in the W3C
Current Patent Practice document.
The Working Group is thus obliged to
produce a specification which relies only on intellectual property
available on a royalty-free basis.

If it proves impossible to produce specifications implementable on
a royalty-free basis, then a Patent Advisory Group will be launched
as described in the W3C
Current Patent Practice document.

Members disclose patent and other IPR claims by sending email to <patent-issues@w3.org>, an archived mailing
list that is readable by Members and the W3C Team. Members must
disclose all IPR claims to this mailing list but they may also copy other
recipients. IPR disclosures are expected to be made public; Members should
specify if their disclosure is confidential.