RE: On the desirable characteristics of standards.

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

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
is, SOAP/WSDL.

-----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 
Standard
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* 
significant
changes in the face of anticipated future developments, and  *minimal* 
changes
in the face of unanticipated developments. The core TCP/IP RFCs are 
excellent
examples of this; the POSIX spec slightly less so.

In the area of web services, we start from a simple base with two 
models:
REST, and SOA SOAP+HTTP. Right now there are three developments that we 
can
anticipate:
- 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 
interesting
ways; taken together, the consequences are hard to imagine at this 
point.
One thing is clear (to me, anyway): the semantics of synchronization and
coordination will change significantly from what we are discussing 
today.
(Consider for example the use cases of an auction, checking 
creditworthiness,
and credit card purchase, as well as the various ways these may be way
composed.)

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 
intrinsic
properties of web services. This appears to conflict with our cautious 
approach
to defining web services in a maximally inclusive and fairly abstract 
way,

Geoff

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