W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2002

RE: D-AG0007- reliable, stable, predictably evolvable - v0x1

From: Damodaran, Suresh <Suresh_Damodaran@stercomm.com>
Date: Wed, 13 Mar 2002 17:10:24 -0600
Message-ID: <40AC2C8FB855D411AE0200D0B7458B2B07C59380@scidalmsg01.csg.stercomm.com>
To: "'Mark Baker'" <distobj@acm.org>
Cc: www-ws-arch@w3.org
Mark,

Thanks for the comments and the pointer.
I hadn't read TBL's article you mentioned, and it was an interesting read.
My responses inline

Regards,
-Suresh
--------------------www.sterlingcommerce.com--------------------------------
Suresh Damodaran Ph.D.                         
Senior Software Architect
469-524-2676(O)
----------------------------------------------------------------------------
----------------                           

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Tuesday, March 12, 2002 8:50 AM
To: Damodaran, Suresh
Cc: www-ws-arch@w3.org
Subject: Re: D-AG0007- reliable, stable, predictably evolvable - v0x1


Suresh,

>  To ensure that the architecture is reliable it should demonstrate the
> following.
> 
> 	R1. All standards should be versioned.
> 	R2  Each release of the WS-A also should be versioned with the
> versions of the standards that go in the WS-A. Such a consistent set of
> versions will be called a "C-set" - for consistent set.

Wouldn't it be better if we gave incremental deployment of a particular
technology at least the same priority as wholesale deployment of a
profile/"C-set"?  IMO, we should give incremental deployment *higher*
priority, but I'd be content with "same priority".

<sd>
What is "priority" here? I have difficulty understanding.
If you are saying that a C-set can have incremental deployment of
a standard/technology ("extensions" is one such increment) without
effecting its C-set version, I am fine with it (provided backward
compatibility is guaranteed. Indeed TBL's partial understanding principle
can be used to justify this, IMHO.
</sd>
 
Of course, this concern trickles down to some of your other points
below.  But rather than dwell on those I'd like to suggest an alternate
R1/R2;

  Evolvability in identified technologies should be considered up front
  so that, as much as possible, this degree of interoperability can be
  achieved.
<sd>
I am trying to be more specific about it to drive towards a set of
quantifiable
requirements. My objection to this sentence is that it doesn't add much
in the way of concrete action. If you think otherwise, will be interested in

knowing more.
</sd>

Some of TimBL's notes on this are here;

http://www.w3.org/DesignIssues/Evolution.html

which also relates to ...

<sd>
Thanks, I will try to fuse in his wonderful ideas into the next rev.
</sd>

> Predictable Evolution of Architecture
> -------------------------------------

I believe that focusing on profiles/C-sets is a bad idea, as it appears
difficult (impossible?) to reconcile this with a goal that also places
emphasis on being predictably evolvable.

<sd>
I fail to see the conflict. C-sets are milestones along the way traveled.
The road doesn't end at the milestone, it continues on.
</sd>

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Wednesday, 13 March 2002 18:10:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:24:56 GMT