W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2003

RE: On the desirable characteristics of standards.

From: Cutler, Roger (RogerCutler) <RogerCutler@ChevronTexaco.com>
Date: Sun, 4 May 2003 21:45:25 -0500
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E01817E12@bocnte2k3.boc.chevrontexaco.net>
To: "Geoff Arnold" <Geoff.Arnold@sun.com>, www-ws-arch@w3.org

Seems to me a fourth anticipated development is some sort of advance in
the way interfaces are described that moves some of the things that are
currently communicated via natural language into the formally described
domain.  The semantic thing.

I have absolutely no idea why anything I have said derives "properties
from certain existing technologies or interactions and project[s] them
as intrinsic properties of web services".  Frankly, I don't even know
what that means.  Some specific examples would probably help me

One other comment that kind of randomly comes to mind -- if the
objective is to make "durable" standards it seems incredibly
counterproductive to me to define the entire scope of the subject --
that is, Web services -- in terms of a specific technology stack -- that

-----Original Message-----
From: Geoff Arnold [mailto:Geoff.Arnold@sun.com] 
Sent: Sunday, May 04, 2003 6:23 PM
To: www-ws-arch@w3.org
Subject: On the desirable characteristics of standards.

I would like to propose that one of the desirable characteristics of a 
is "durability", which to me is synonymous with "future-proof". It 
means that
the document is constructed in such a way that it requires *no* 
changes in the face of anticipated future developments, and  *minimal* 
in the face of unanticipated developments. The core TCP/IP RFCs are 
examples of this; the POSIX spec slightly less so.

In the area of web services, we start from a simple base with two 
REST, and SOA SOAP+HTTP. Right now there are three developments that we 
- multiple types of message transports
- choreography (which I interpret as MEP composition)
- multiparty interactions
Each of these developments will affect the web services model(s) in 
ways; taken together, the consequences are hard to imagine at this 
One thing is clear (to me, anyway): the semantics of synchronization and
coordination will change significantly from what we are discussing 
(Consider for example the use cases of an auction, checking 
and credit card purchase, as well as the various ways these may be way

All of the examples suggested by Assaf, Roger, Suresh, Ugo, and Mike 
seem to
me to fail the "durability" test. They seem to derive properties from
certain existing technologies or interactions and project them as 
properties of web services. This appears to conflict with our cautious 
to defining web services in a maximally inclusive and fairly abstract 

Received on Sunday, 4 May 2003 23:03:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:06 UTC