- From: FABLET Youenn <fablet@crf.canon.fr>
- Date: Thu, 21 Feb 2002 16:57:49 +0100
- 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