D-AG0005 - Simplicity Requirement

This is my "get the ball rolling" message I agreed to post:

The current wording of this requirement says simply "provides simplicity and
ease-of-use that does not impose high barriers	to entry for users of web
services".  As we discussed today, there are several dimensions to
"simplicity and ease of use" that need to be brought out in our
deliberations, and possibly in the requirements.

First, is "simple for whom?"  We identified three types of uses of our
architecture:
- Spec writers in WG's defining components we identify (e.g., the WSD WG)
- Programmers implementing those specifications
- End-users of those implementations (e.g., customers using a web services
IDE)

Also, "simplicity" of what we produce means different things:
- The exposition of the architecture is easy to understand -- clear prose,
helpful illustrations, etc.
- A small number of concepts and relationships suffices to describe the
architecture
- The target audience has little difficulty using the architecture

Furthermore, there are tradeoffs among these goal.  For example, a truly
minimal and elegant definition of the architecture would probably use
formalisms that made it difficult for much of the audience to understand.
Likewise, "minimilistic" approaches in general are easy to understand and
implement, but cumbersome to use because they lack "convenience classes" to
do common things in a way that simplifies life for the end user while making
more work for the implementer.

Here's some strawman language that is a first attempt to reconcile all this:

"The W3C Web Services Reference Architecture is intended primarily for the
use of other working groups specifying the components identified in the
architecture, secondarily for developers implementing the components, and
incidentally for end users of those components.  The exposition of the
reference architecture MUST, to the greatest extent feasible, be
understandable by a "typical" experienced software designer/developer: it
should use a minimum of specialized jargon, employ simple declarative
sentences wherever possible, and be organized and illustrated in a way to
minimize the amount of effort required to understand it.  The reference
architecture SHOULD specify as few components and relationships as are
minimally necessary meet the other requirements. The reference architecture
MAY, within the other contstraints, describe use cases and examples intended
to clarify how an application programmer would use its components to build
typical applications that utilize web services."

Flame away ...

Received on Thursday, 7 March 2002 21:18:27 UTC