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

Re: On the desirable characteristics of standards.

From: Walden Mathews <waldenm@optonline.net>
Date: Mon, 05 May 2003 00:20:02 -0400
To: Assaf Arkin <arkin@intalio.com>
Cc: www-ws-arch@w3.org
Message-id: <000c01c312bd$99fb2d80$1702a8c0@WorkGroup>

> In my opinion for the semantic of WSDL operations to become 
> "future-proof" they must be independent from any particular choice of 
> SOAP MEPs used to implement them, including the best practices of today. 
> In other words, the function synchronous(WSDL_MEP) should not be defined 
> in terms of synchronous(SOAP_MEP), but defined on its own.


I'm just wondering about the formality: 'synchronous(WSDL_MEP)'
and how it plays in terms of process algebras you might imagine, or
doesn't.  I guess what I'm asking is, is this a formality that can be
plugged in to some formula and used to derive a truth about some
WS composition, or is it just a formal-looking notation for what will
remain a somewhat informal notion?

WS Arch Group (in general),

I think Extreme Programming would circumvent this boondoggle
over the "right" definition for synchronous and asynchronous by
simply having each author of a section of the document who would
use that term go instead to the next level of detail and inline the
intended attributes right into the text.  So, if you were talking about
time dependency, you'd simply describe that.  If you were talking
about "channels", you'd say that.  And so on.

When the document is finished, you may have an opportunity to
factor out attributes and actually have consensus on these terms,
or you may not.  In the process, you have expressed with precision
and gotten on with it.

One thing is sure: when you're done writing the arch document,
you are certain of the scope in which the definitions have to operate,
something which cannot be achieved until that time.

W.r.t. this problem, what is the "simplest thing that could possibly
work"?  I submit the above for your serious consideration.

Received on Monday, 5 May 2003 00:20:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:51 UTC