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

Fwd: Analysis of WSD Requirements by WS Arch

From: Philippe Le Hegaret <plh@w3.org>
Date: 12 Jun 2002 11:12:56 +0200
To: www-ws-desc@w3.org
Message-Id: <1023873177.4440.11.camel@chacal>

--------------------
Subject: Analysis of WSD Requirements by WS Arch
Date: Fri, 24 May 2002 16:49:45 -0400

Analysis of WSD Requirements by WS Arch

General observations:
1) Independent design - reqs, scenarios, components, interfaces -  of
    overlapping problem space will certainly result in redundancy and
    defintion skew. This is happening with WS Arch and WS Desc.
2) Minimally, WS Arch should consider adopting a number of WS Desc reqs
3) Maximally, construct a similiar situation between WS Arch and WS Desc
    based on the earlier partitioning of interaction modeling into Usage
    Scenarios (WS Arch owned) vs Use Cases (WS Desc). Hence WS Arch
would
    push down requirements on other WS WGs much like the TAG is pushing
down
    the definition of the Web onto WS Arch.

    Question: Should overlaping requirements be
    1) defined independently (current situation)?
    2) held joinly as peers? - involves an joint actitity
    3) owned by WS Arch and pushed down on WS Activity WGs?
    My biased answer:
    (1) is easiest, inconsistencies can be identified (start from (3)
below)

Actions:
1) Verify glossary terms are consistent & shared. They define: Message,
Operation,
Interface (aka Port Type), Interface Binding, Endpoint, and Service.


2) Consider adoption of non-overlapping, high-level WS Desc
requirements:
--------------
R004 The WG specification(s) MUST describe constructs using the [XML
Information Set] model (similar to the SOAP 1.2 specifications
[SOAP 1.2 Part 1]).

PROPOSED ACTION: Move R004 to D-AC010.2 which is now D-AC011.3.2(?).
Reword
to be WG agnostic.
---------------
R100 The description language MUST allow other type systems besides XML
Schema (http://www.w3.org/2001/XMLSchema) via extensibility.

PROPOSED ACTION: Adopt this unless we feel that the CSF D-AC010.1
sufficiently
covers this. Adopt as AC-011.3.3 (?)
--------------
R098 The WG specification(s) schema and examples MUST be written in XML
Schema
and SHOULD be written in the latest public W3C XML Schema
Recommendation.

PROPOSED ACTION: Not sure - may be too low level except as a good
push-down req
--------------


3) Redundant, scope-changed, or slightly askew WSD requirements relative
to WSA:
--------------
R070 The WG specification(s) MUST allow providing a mapping from the
description language to [RDF]. (See AC009)
--------------
R001 The description language MUST allow any programming model,
transport,
or protocol for communication between peers. (AC011, AC021)
--------------
R099 Processors of the description language MUST support XML Schema (See
AC010.1)
--------------
R007 The WG specification(s) MUST provide detailed examples, including
on-the-wire messages.  (See AC012)
--------------
R003 The WG specification(s) SHOULD use available XML technologies. (See
AC010)
--------------
R105 The WG specification(s) SHOULD support Web Services that operate
on resource constrained devices. (See AC021)
--------------
R010 The WG specification(s) SHOULD use consistent terminology across
all
sections of the specification(s). (See AC012)
--------------
R013 The WG specification(s) MUST be simple to understand and implement
correctly.
The description language MUST be simple to use. (See AC005)
--------------
R014 The WG specification(s) SHOULD be compatible with existing Web
infrastructure. (See AC011)
--------------
R012 The description language 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,
the
description language MUST support distributed extensibility.  (See AC003
and
AC011)
-------------



4) Potential high relevance to WSA. These WS Desc Requirements may
impact
WS Arch work:
--------------
R022 The description language MUST allow describing application-level
error
Messages (AKA faults) generated by the Web Service.
--------------
R054 The description language MUST clearly separate the description of
Messages
from the Message exchange pattern and InterfaceBinding.
--------------
R116 The description language MUST allow describing abstract policies
required
or offered by Services.
--------------
R083 The description language MUST separate design-time from run-time
information.
--------------
R117 The description language SHOULD allow specifying QoS-like policies
and
mechanisms of a Web Service. For instance, an indication of how long it
is
going to take a Web Service to process the request.
--------------
R036, R097, R094 "These are assertions of what type of message
interactions
will be supported (described). Listed are: one-way (self to self),
request-
response, solicit-response, faults, asynchronous, events
(output-oriented)."
--------------
R081 The description language MUST describe EndPoint location using
URIs.
--------------
R046 The description language MUST allow describing Messages independent
of
specific wire format.
--------------
R046, R085 "Service types are groups of interfaces - ST groupings can be
extended"
--------------
R114 The description language MUST allow unambiguously mapping any
on-the-wire
Message to an Operation.
--------------
R068 The description language MUST allow binding of transport
characteristics
independently of data marshalling characteristics.
--------------
R052 The description language MUST allow describing InterfaceBindings to
other
protocols besides those described in the specification.
--------------
R111 The WG MUST provide a normative description of the InterfaceBinding
for
HTTP/1.1 [IETF RFC 2616] GET and POST.
--------------
R028 The description language MUST allow describing the structure of
incoming
and outgoing SOAP 1.2 messages [SOAP 1.2 Part 1], including the
contents, encoding,
target, and optionality of SOAP 1.2 Header and Body blocks, SOAP RPC
blocks, and
SOAP Faults.
--------------
R031 The WG specification(s) SHOULD support SOAP 1.2 intermediaries.
--------------
R075 The description language MUST allow identifying versions of
Services. "(Not
just description files)"
--------------
R115 The WG specification(s) SHOULD define the equivalence of Service
descriptions.
--------------
Received on Wednesday, 12 June 2002 05:13:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:20 GMT