RE: Reqs extracted from xmlp req list

Youenn (and Jean-Jacques), nice to see this thorough list. Several
appear to already be covered by existing requirements; I added new
requirements for those that appear to be new. In both cases, I noted my
understanding in [square brackets].

If I have misunderstood a requirement, please let me know. It is not my
intention to be a strong filter on requirements at this point.

Thanks again.

--Jeff

-----Original Message-----
From: FABLET Youenn [mailto:fablet@crf.canon.fr] 
Sent: Thursday, February 21, 2002 7:58 AM
To: www-ws-desc@w3.org
Cc: Jean-Jacques Moreau
Subject: Reqs extracted from xmlp req list


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.
[jeffsch: Use Cases Waqar is editing.]

The specification will make reasonable efforts to support (but not
define) a broad range of programming models suitable for the
applications intended for WSD.
[jeffsch: R001: The language developed by the WG must not preclude any
programming model, nor assume any transport or protocol for
communication between peers.]

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.
[jeffsch: DR002: Coordinate with W3C XML Activity and XML Coordination
Group. DR003: Use available XML technologies wherever possible.]

The specification developed by the Working Group shall be as lightweight
as possible keeping parts that are mandatory to the minimum.
[jeffsch: DR017: Specification shall be as lightweight as possible,
keeping parts that are mandatory to a minimum.]

Optional parts of the specification should be orthogonal to each other
allowing non-conflicting configurations to be implemented.
[jeffsch: DR018: 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.
[jeffsch: DR016: Be simple to understand and implement correctly;
comparable to other 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.
[jeffsch: New DR102.]

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.
[jeffsch: New DR103.]

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)).
[jeffsch: New DR104.]

WSD and applications of WSD must be easy to deploy, especially in
systems already supporting XML technologies like XML namespaces and XML
schemas.
[jeffsch: DR014: 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.]

The WSD specification must support using XML Schema simple and complex
types.
[jeffsch: R099: WSDL 1.2 processors must support XML Schema
(http://www.w3.org/2001/XMLSchema *). DR048: Must be able to describe
messages using XML Schema simple and complex types.]

WSD should facilitate the creation of simple applications.
[jeffsch: DR019: Facilitate the creation of simple applications (fast
and easy writing for simple apps).]

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.
[jeffsch: DR036: 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.]

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.
[jeffsch: DR012: 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 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.
[jeffsch: New DR0105.]

The WSD specification must define a means to describe the possible fault
messages that may be generated by a web service.
[jeffsch: DR022: The language must also describe the error messages
generated, if any. DR039: Must be able to describe simple
request-response-fault message exchange.]

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. 
[jeffsch: Use Cases Waqar is editing.]

(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 ?))).
[jeffsch: These feel out of scope of WSDL, and more in the scope of
things like WS-Routing / WS-Referral:
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglob
spec/html/wsroutspecindex.asp>,
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglob
spec/html/wsreferspecindex.asp>.]

Received on Monday, 25 February 2002 17:57:42 UTC