- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Thu, 29 May 2003 13:56:34 -0500
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
I think that this is very good. I particularly strongly agree with [1], and I feel that this insight is a very important one. -----Original Message----- From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] Sent: Thursday, May 29, 2003 1:42 PM To: www-ws-arch@w3.org Subject: 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:59:23 UTC