W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2002

Reqs extracted from xmlp req list

From: FABLET Youenn <fablet@crf.canon.fr>
Date: Thu, 21 Feb 2002 16:57:49 +0100
Message-ID: <3C7518FD.2000602@crf.canon.fr>
To: www-ws-desc@w3.org
CC: Jean-Jacques Moreau <moreau@crf.canon.fr>
We went through the XMLP requirements document[1] and extracted a
number of requirements that we thought were equally applicable to
WSD (after some amount of transformation). The meatier
requirements are at the end.

We are sorry if this is coming out late.

Youenn and Jean-Jacques.

[1] http://www.w3.org/2000/xp/Group/xmlp-reqs-06/

The WSD requirements must include usage scenarios that describe
how WSD is used in various environments. The set of usage
scenarios must represent the expected range of WSD's use. The
scenarios must be used as design cases during the development
of WSD, and it must be possible to determine whether or not the
WSD design enables each scenario. In addition, the usage
scenarios are intended to help a technically competent person
understand the role of WSD.

The specification will make reasonable efforts to support (but
not define) a broad range of programming models suitable for
the applications intended for WSD.

The Working Group will coordinate with the W3C XML Activity
through the XML Coordination Group (W3C members only) and shall
use available XML technologies whenever possible. If there are
cases where this is not possible, the reasons must be
documented thoroughly.

The specification developed by the Working Group shall be as
lightweight as possible keeping parts that are mandatory to the
minimum. Optional parts of the specification should be
orthogonal to each other allowing non-conflicting
configurations to be implemented.

WSD must be suitable for widespread use across organizational
boundaries in support of the application usage scenarios
supplied elsewhere in this document. This suitability
requirement implies simplicity in the language of the WSD
specification, which itself describes a technology that is
simple to understand and to implement correctly. Although
simplicity can only be measured in relative terms, the Working
Group should ensure that the complexity of any solution
produced is comparable to that of other current and widespread
Web solutions.

Since WSD is intended to be a foundation service description
language, its definition should remain simple and stable over
time. Explicit use of modularity and layering in the resulting
design will help assure longevity. Such a framework will allow
subsequent extension of the design while leaving the foundation
of the design intact.

The WSD specifications should be clear and easy to understand.
This clarity implies that considerable editorial effort will be
required in the structuring of the narrative through both
outline/overview and normative reference material.

The WSD specification must clearly identify conformance
requirements in a way that enables the conformance of an
implementation of the specification to be tested (see also the
W3C Conformance requirements (W3C members only)).

WSD and applications of WSD must be easy to deploy, especially
in systems already supporting XML technologies like XML
namespaces and XML schemas.

The WSD specification must support using XML Schema simple and
complex types.

WSD should facilitate the creation of simple applications.
Simple applications are often characterized by message exchange
patterns such as one-way (or event), and two-way (or
synchronous) request response interactions.  The specification
should make such simple exchange applications as easy as
possible to create and to use.

WSD must support extensibility of vocabulary between
communicating parties in a way that allows for decentralized
extensibility. The WG must demonstrate through usage scenarios
that the solution supports decentralized extensibility in a
modular and layered manner. To date the web has been enormously
successful because it has enabled the creators of web services
adapt the user interfaces they provide to human users of the
web. A goal of WSD is to achieve similar levels of
evolvability, extensibility and adaptability for interfaces
between web services.

The WSD specification should make reasonable efforts to support
applications that operate on resource constrained devices. Even
though any practical device is resource constrained in any
number of dimensions including but not limited to bandwidth,
computational power and storage, the term "resource constrained
device" often refers to hand-portable devices. This document
does not attempt to define the term "resource constrained" nor
what the constraints are for the available resources.

The WSD specification must define a means to describe the
possible fault messages that may be generated by a web service.

The WSD specification must consider the scenario where an XMLP
message may be routed over possibly many different transport or
application protocols as it moves between intermediaries on the
message path. 
(Not sure if this one is relevant... 
it might nevertheless raise some issues.
Like should a WS describe some kind of message path for its response? 
What about an answer that needs a different protocol than the request ?
Should a WS describe that it will answer directly to the initiator or the last intermediary? (important if we would like streaming a response (implementation stuff ?))).
Received on Thursday, 21 February 2002 10:59:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:37 UTC