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

Suresh,

> 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.

My concern was that the granularity of interoperability would be a set
of specifications, rather than individual ones.

As an example, the Web evolved, and continues to evolve, with various
versions of protocols (HTTP 1.0, HTTP 1.1) and data formats (HTML 2.0,
HTML 3.2, HTML 4.0, CSS 1, CSS 2, etc..).  If special treatment was
given to demonstrating the conformance of, say, HTTP 1.0 + HTML 3.2 +
CSS 1.0 (i.e. if that were a C-set), without considering the needs of
those who want to use HTTP 1.1 + HTML 3.2 + CSS 1 (not a C-set), then to
me, that introduces an evolutionary problem.

Practically, it also places a large burden on small ISVs or open source
developers to develop code that implements these specifications in
parallel so that they can be deployed at the same time.  IMO, this
unnecessarily favours large corporations.

Also, re versioning, consider that URIs aren't versioned, despite their
evolution over time with different RFCs (1738,1808,2396).  Should the
Web services architecture include such a key architectural component as
a URI, it should not necessarily be versioned in the traditional sense
of the word - it should be required to remain backwards compatible with
previous specifications, but more importantly, deployed software.

> 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>

Well, I think I'm saying more than that.  I'm saying that we shouldn't
define C-sets at all.  More below ...

>   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>

I think "backwards compatible" is a good testable requirement, so we
could add that.  Also, re above, I think it would be useful to actually
*exclude* any mention of C-sets in our work.

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

Great.

> > 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>

Sure.  But if these steps are given special consideration (conformance
testing, etc..) that incremental steps don't get, then incremental
evolution is necessarily working from a handicap.

If WS-I wants to define C-sets, and conformance test around that, that's
their perogative.  But an architecture, especially one built on the Web,
should not require it, IMO.

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 23:20:21 UTC