RE: D-AG0005 - Simplicity Requirement

Another aspect of simplicity is re-use between specifications.  I would like
to ensure that data elements that are common across various modules of web
services are re-used, rather than copied.  A simplicity goal is that common
data elements are not duplicated in messages or descriptions when multiple
modules are mixed together.  An example would be a messageID that might be
required for correlation, reliability, and security headers.  We don't want
this ID to be duplicated in 3 different soap headers.

Another aspect of simplicity is re-use of existing extensibility mechanisms.
We do not want to recreate existing extensibility mechanisms, such as SOAP
envelope or XML extensibility.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Champion, Mike
> Sent: Thursday, March 07, 2002 6:18 PM
> To: www-ws-arch@w3.org
> Subject: 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 Tuesday, 12 March 2002 12:49:12 UTC