Redrafting section 2.1 - Intro to concepts section

Reviewing the minutes from Rennes to try to identify specific action items
to the editors, I found it easier to just try my hand at redrafting these
paragraphs rather than try to explain what we agreed.  Consider this a
strawman [with obviously controversial parts marked clearly].  We need to
either find someone to "own" this section and drive us toward consensus, or
accept the strawman and let the editors wordsmith.

=============================================================

The formal core of the architecture is this enumeration of the core concepts
and relationships that are common to most vendor-specific Web service
architecture visions and implied by Web services specifications. 
[1]

Each concept is presented according to a common template consisting of our
relatively formal definition of the concept, an enumeration of the
relationships with other concepts, and a "natural language" discussion of
what this all means.  The concept definitions and relationships are intended
to be definitive and precise, but the descriptions are intended to enhance
general and informal understanding.  In general, the concepts are expressed
as nouns and the relationships expressed as verbs [2].


The ordering of the concepts in this section is alphabetical; this should
not be understood to imply any relative importance. For a more focused
viewpoint the reader is directed to the Stakeholder's perspectives section
which examines the architecture from the perspective of key stakeholders of
the architecture.

The reason for choosing an alphabetical ordering is that, inevitably, there
is a large amount of cross-referencing between the concepts. As a result, it
is very difficult, if not misleading, to choose a non-alphabetic ordering
that reflects some sense of priority between the concepts. Furthermore, the
`optimal ordering' depends very much on the point of view of the reader.
Hence, we devote the Stakeholders perspectives section to a number of
prioriterized readings of the architecture.

================================================================

The next two paragraphs in 2.1 need to be reworked and probably put in
either the INTRODUCTION or the FUNDAMENTAL CONCEPTS section.  They talk
about "conformance", which is a very slippery concept when we're talking
about a reference architecture from a group that has no authority to enforce
it.  I'll send a separate message on that.


[1] The old draft talks about interoperability and implementations; my sense
of the discussions at Rennes is that we are only seeking to guide specs
rather than implementations.  Interop is both a spec-level rather than
architecture-level issue (for the most part!) and something that is clearly
in the domain of the WS-I.  I think our goal is to clarify the vision not
define a direct basis for interoperability. Based on a couple of 1:1
discussions with TimBL, the sense in Rennes was "we will succeed when we can
define Web Service and show how the pieces (description, messaging,
choreography, etc. etc. etc.) fit together."

[2] I'm not sure we agreed on this, but it seemed like a good idea to most
of us in Rennes.

Received on Thursday, 29 May 2003 14:42:18 UTC