RE: Web Services Description: Requirements

Hi, Jeff,

Please add the following requirements to the list for the WG's
consideration. 

[Correct errors/inconsistencies in WSDL1.1]
I will post a separate message for a list of errors we have identified in
our implementation of WSDL1.1 specification

[Distinction between Interface definition and Implementation definition]

A description of a web service can be logically divided into three parts:
Data type definition, Service Interface definition and Service
Implementation definition. The data type definition can be viewed as part of
the Service Interface Definition. Analogous to defining an abstract
interface in a programming language and having many concrete
implementations, a service interface definition can be instantiated and
referenced by multiple service implementers.

WSDL 1.1 specification implies such a division by providing the mechanism
for dividing a service definition into multiple WSDL documents. WSDL1.1
Section 2.1.2, Authoring Style, shows an example of separating a complete
service definition into three documents: data type definition, abstract
definitions and specific service bindings. 
However, this distinction is not clear and reference to each unit is very
difficult. To facilitate easier allocation of responsibilities among
different organizations (such as standard bodies and service providers) or
among different teams within an organization (such as teams related to the
different stages of a service's lifecycle: design time/development time,
configuration time and run time), a better distinction between Interface
definition and Implementation definition should be made in the
specification.
   
The final WSDL specification should be divided into two parts: the first
part only focuses on the core interface definition language, and the second
part addresses the binding extensions .  

[Better Specification for Binding Extensions]
In addition to the core service definition framework, WSDL1.1 introduces
specific binding extensions for SOAP 1.1, HTTP GET/POST and MIME, and
nothing precludes the use of other binding extensions. 
To keep the core service definition framework simple, a separate and more
detailed specification or technical report should be dedicated for various
bindings. 

[Better Specification for Document Name and Linking]
WSDL1.1 section 2.1.1 is over simple. More detailed specification should be
provided to define how the import mechanism works, especially how it's
related to the import and include mechanism defined in the XML Schema
specification.

[Best Practices and Conformance Test]
Although a few examples are given in WSDL 1.1 specification, the examples
are not sufficiently explained in the text, and no corresponding wired
message examples are available for different binding definitions.  To help
clearer interpretation of the specification, more consistent and detailed
examples should be provided.
In addition, a technical report associated with the WSDL specification
should be dedicated to provide:
·	Use cases which illustrate typical usage scenarios of WSDL 
·	Best practices  
·	Conformance test suite 

[Up-to-date XML Schema Support] 
In all WSDL 1.1 examples, the October 2000 version of the XML schema is
used:
	 http://www.w3.org/2000/10/XMLSchema 
We understand that the 10/2000 schema was the most up-to-dated schema
available at the time WSDL1.1 was released. However, in future versions of
WSDL specification, the W3C recommendation version of the XML schema should
be used. The recommendation was released in May 2001:
	http://www.w3.org/2001/XMLSchema 

[Easy Interaction with Upper layers in the web services stack] 
Additional technologies will be required in the future to complete the web
services architecture. As one of the fundamental layers of the web services
stack, though WSDL should not depend on any other layers, one of the design
goals of WSDL should be easy interaction with upper layers, such as services
composition layers

[Editorial Improvements]
Consistent Terminologies
Consistent terminology should be used across all the sections of the
specification. As one example, the usage of the terms "port" and "endpoint"
is confusing to many readers. Though it states that "port" is "a single
endpoint defined as a combination of a binding and a network address", the
specification uses "port" and "endpoint" interchangeably in many places.   

Diagrams
Some diagrams that explain the structure of core WSDL elements and their
relationship will help reduce misinterpretations. 

Regards,
Kevin Liu
Technology Architect, 
SAP Labs, Palo Alto
650-849-5167


-----Original Message-----
From: Jeffrey Schlimmer [mailto:jeffsch@windows.microsoft.com]
Sent: Friday, February 08, 2002 6:12 PM
To: www-ws-desc@w3.org
Subject: Web Services Description: Requirements


One of the first activities of the W3C Web Services Description Working
Group is to draft a set of requirements and scenarios for the working
group. Per our first teleconference, below is a draft list of
requirements; the list is an individual contribution -- it does not
reflect any decisions of the working group -- all mistakes are mine.

Please review the list and provide feedback.

--Jeff


WEB SERVICE DESCRIPTION REQUIREMENTS

MESSAGES (TYPES, MESSAGE) (1xx)

Must be able to describe messages independent of specific wire format.

(No requirement to describe semantic content of messages.)

Must be able to describe messages using XML Schema simple and complex
types.

Must be able to describe messages using other info sets.

Must be able to extend message descriptions using mechanisms not
explicitly identified in the spec.

Must be able to describe messages that include arrays and nested arrays.

Must be able to describe XML Protocol messages.

Must provide a normative description for XML Protocol messages.

Must be able to describe XML Protocol Header elements and Body elements.

Must be able to describe XML Protocol Faults.

Must be able to describe messages of other protocols.


PORT TYPE (and OPERATION) (2xx)

Must be able to describe simple one-way messages, i.e., either incoming
or outgoing (event) messages.

Must be able to describe simple request-response-fault message exchange.

(Not a requirement to describe arbitrary message exchanges.)

Must be able to describe sets of messages that form a logical group
(i.e., a port type).

Must be able to derive a port type from another by extension of the
logical group of messages.

Must be able to extend protocol descriptions using mechanisms not
explicitly identified in the spec.


SERVICE TYPE (3xx)

Must be able to describe a logical group of port type instances (i.e., a
service type).

Must be able to name an instance of a port type.

Must be able to derive one service type from another by extension of the
logical group of port instances.

Must be able to extend service descriptions using mechanisms not
explicitly identified in the spec.


TRANSPORT / BINDING (4xx)

Must be able to describe the wire format of messages, whether XML,
ASCII, binary, or some combination.

Must provide a normative description of the binding for XML Protocol.

Must be able to describe bindings to other transports.

Must be able to extend transport binding descriptions using mechanisms
not explicitly identified in the spec.


ENDPOINT (5xx)

Must be able to describe endpoint location using URIs.

Must be able to describe address for specific port instances within a
service.

Must be able to separate design-time from run-time information.


OTHER (9xx)

REUSABLE

Must be able to partition a description across multiple files.

Must be able to use a description fragment in more than one description.

EXTENSIBLE

Must define a set of constructions to indicate which extensions are
optional versus mandatory.

VERSIONING

TODO


GENERAL REQUIREMENTS (0xx)

Coordinate with W3C XML Activity and XML Coordination Group.

Use available XML technologies wherever possible.

Describe constructs using the XML Infoset model.

SIMPLICITY AND STABILITY

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.

INTEROPERABLE

Simple to understand and implement correctly; comparable to other
widespread Web solutions.

SECURITY

Compliance must not preclude building implementations that are resistant
to attacks.

TESTING

TODO

EXTERNAL REQUIREMENTS

P3P REQUIREMENTS


EOF

Received on Tuesday, 12 February 2002 14:24:59 UTC