[RTF] Rewording D-AG002 & D-AC007

Hi Hao,

Thanks for your input below.
I have created a new version for D-AG002 as well as D-AC007 (I have
included the essence of your statements, many of which I agree).
I also went over the comments during the ballot [1b] for this exercise for
inspiration,
as well as [3].
Basically, reliability deals with a "snapshot" of the arch., whereas
stability
deals with changes to the snapshot. Evolution is possibly covered in
extensibility,
and is not addressed. 
I also propose that we merge 19.1 & 2 (both were accepted during ballot)
with AC007
(I have not included it here, but I can, after we discuss it)

Also look for specific inline comments in your mail.
Let us discuss this in the meeting.

Regards,

-Suresh
Sterling Commerce   
[1a] http://www.w3.org/TR/2002/WD-wsa-reqs-20020429
[1b] http://lists.w3.org/Archives/Member/w3c-ws-arch/2002May/0127.html
[3] http://lists.w3.org/Archives/Public/www-ws-arch/2002Apr/0016.html
-----------------------------------------------------
D-AG002
The Web Service Architecture must enable creation and execution of reliable,
stable, and measurable web services.


D-AC007.1 The Web Service Architecture must enable creation and execution of
reliable web services.

      D-AR007.1.1 The Web Service Architecture identifies and defines all of
its components precisely and unambiguously.
            D-AR007.1.1.1. There is a unique identification scheme for
identifying each    
            component, and all components are identified using this
identification scheme.

            D-AR007.1.1.2 The terms and language used to describe the Web
Services 
            Architecture and its components are unambiguously defined.

      D-AR007.1.2 The definition and use of the components is consistent
within the WSA.

      D-AR007.1.3 The static and dynamic relationship between components is
clearly identified and defined. 

      D-AR007.1.4 The WSA should provide clear non-normative guidelines for
the use of the architecture and its components wherever applicable.

      D-AR007.1.5 The reference architecture must be validated against WSA
use cases.

      D-AC007.2 The WSA must enable creation and execution of stable web
services.

	      D-AR007.2.1 When a component within the WSA changes, the
change is precisely identified, and the changed WSA is reliable.
  	      D-AR007.2.2 The WSA has a clearly defined versioning policy
for the architecture and its components.
	      D-AR007.2.3 The assumptions behind a change in the component,
and its scope must be clearly stated.


-------------------------------------------------------------------------



-----Original Message-----
From: Hao He [mailto:Hao.He@thomson.com.au]
Sent: Monday, June 17, 2002 4:07 PM
To: Damodaran, Suresh; ''Christopher Ferris' '
Cc: ''Heather Kreger' '; ''Dilber, Ayse, ALASO' '; ''ECKERT,ZULAH
(HP-Cupertino,ex1)' '
Subject: Rewording about D-AC007


hi, All,

Since I promise to reword 007, here are my thoughts:

If we just consider the top-level characteristics of an architecture. We
want
it to be:

1. Simple but not simpler so developers can implement it easily.
2. Reliable (it means the following aspects:
  2.1 Correct and consistent so there are no fundamental flaws in the
architecture.
  2.2 Precisely defined so there is no ambiguity.
  2.3 Can be validated against use cases. )
3. Stable and evolutionary. This means developers can build on previous
implementation without starting from scratch when each new version is
released.
Part of the solution is to allow a good framework of extensibility. This is
already outlined in other goals.  There is another aspect of this issue: the
architecture must have correctly identified all the fundamental problem and
uses
an iterative approach.  This also requires a standard policy on versioning. 
4. Scalable. This has already be dealt with by other goals.

     
D-AC007 mainly deals with 2 and 3. I therefore propose the following
re-wording to
AC-007:


<D-AC007>
    is reliable, and stable, and evolutionary.
    
 7.1 The reference architecture is reliable:
 7.1.1 The reference architecture is correct and consistent.
<sd> "correct" with respect to what? Doesn't 7.1.3 cover this (unless you
intended something different) </sd>
 7.1.2 The reference architecture is precisely defined without ambiguity,
 7.1.2.1 using standard definition languages whenever applicable and
available,
 7.1.2.2 using standard terms, and clearly defined new terms.
 7.1.3 The reference architecture must be validated against use cases.
 
 7.2 The reference architecture is stable and evolutionary.
<sd> removed "evolutionary" </sd>
 7.2.1 The reference architecture has stable fundamentals including
assumptions and scope.
 7.2.2 The reference architecture has a well defined versioning policy.
 7.2.3 Newer versions must be compatible with older versions.
<sd> sometimes new versions may not be compatible - isn't it sufficient to
be
precise on the change> </sd>
 
 
 I propose to remove 7.2.4 and all of 7.3
 Reasons:
 7.2.4 references to other standards have already been considered by other
goals
 7.3.1 This can be solved by extensibility.
 7.3.2 This can be solved by extensibility.
<sd> I am not sure this is covered by extensibility yet - I have inserted it
in reliability.
I agree on 7.2.4 and 7.3.1 </sd>

</D-AC007> 
 

Hao He

Received on Tuesday, 18 June 2002 00:35:30 UTC