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
    push down requirements on other WS WGs much like the TAG is pushing
    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)

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

2) Consider adoption of non-overlapping, high-level WS Desc
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(?).
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
covers this. Adopt as AC-011.3.3 (?)
R098 The WG specification(s) schema and examples MUST be written in XML
and SHOULD be written in the latest public W3C XML Schema

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,
or protocol for communication between peers. (AC011, AC021)
R099 Processors of the description language MUST support XML Schema (See
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
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
sections of the specification(s). (See AC012)
R013 The WG specification(s) MUST be simple to understand and implement
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
seen on the Web: disparity of document formats and protocols used to
mixing of XML vocabularies using XML namespaces, development of
solutions in a
distributed environment without a central authority, etc. In particular,
description language MUST support distributed extensibility.  (See AC003

4) Potential high relevance to WSA. These WS Desc Requirements may
WS Arch work:
R022 The description language MUST allow describing application-level
Messages (AKA faults) generated by the Web Service.
R054 The description language MUST clearly separate the description of
from the Message exchange pattern and InterfaceBinding.
R116 The description language MUST allow describing abstract policies
or offered by Services.
R083 The description language MUST separate design-time from run-time
R117 The description language SHOULD allow specifying QoS-like policies
mechanisms of a Web Service. For instance, an indication of how long it
going to take a Web Service to process the request.
R036, R097, R094 "These are assertions of what type of message
will be supported (described). Listed are: one-way (self to self),
response, solicit-response, faults, asynchronous, events
R081 The description language MUST describe EndPoint location using
R046 The description language MUST allow describing Messages independent
specific wire format.
R046, R085 "Service types are groups of interfaces - ST groupings can be
R114 The description language MUST allow unambiguously mapping any
Message to an Operation.
R068 The description language MUST allow binding of transport
independently of data marshalling characteristics.
R052 The description language MUST allow describing InterfaceBindings to
protocols besides those described in the specification.
R111 The WG MUST provide a normative description of the InterfaceBinding
HTTP/1.1 [IETF RFC 2616] GET and POST.
R028 The description language MUST allow describing the structure of
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
Received on Wednesday, 12 June 2002 05:13:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:23 UTC