RE: Harvesting experience as well as architectures

Mike

I agree with your summary, yet I think we have particular problem to solve
which makes life a bit more difficult.

Specifically SOAP is very simple which means you have to use SOAP extensions
to it to make it useful. However there are very many different target uses
for the base SOAP, for example:
* Inter-server communication - e.g. to link real-time process control
computers in a manufacturing environment
* Remote access to data - e.g. remote database update
* Secure reliable eCommerce across firewalls
* Synchronization of data with a PDA

These have very different requirements, for instance:
* Remote database update might need two phase commit
* eCommerce would need public key cryptography
* Inter-server communication would have to be very efficient

The problem is that I don't think that one size fits all. So even if we want
to go for the 80/20 rule (which I agree is a good idea) which 80% do we go
for as one person's nice to have is another's must have ... thoughts?

David
-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
Sent: Sunday, July 14, 2002 5:52 AM
To: www-ws-arch@w3.org
Subject: Harvesting experience as well as architectures



[reposting to public list at Chris's suggestion]

Tim Bray (one of the original XML editors, current TAG member) has posted a
couple of very thoughtful messages recently that I think we should "harvest"
for ideas on how to actually pull the WSA together.  I'm thinking
specifically of

http://lists.w3.org/Archives/Public/public-qt-comments/2002Jul/0007.html
http://lists.w3.org/Archives/Public/www-tag/2002Jul/0175.html

These imply some lessons that we might learn from the other activities that
could be useful in guiding the WSA.  Of course, I'm sure that some of you
know much more about the specs that Tim alludes to than I do, and you may
take very different "lessons" from the experience.  Feel free to set me (or
Tim) straight,  but I think it is important for us as individuals to think
these through and come up with a personal orientation ... as the old saw
goes, "those who ignore history are doomed to repeat it."

Summarizing, and possibly putting words in Tim's mouth that he may not agree
with, some lessons from other W3C activities that we may wish to learn are:

-  Make an effort to hit the 80/20 point rather than trying to carve out a
complete solution; given the lack of concrete experience at the bleeding
edge of XML technologies (query languages, schema languages, web services,
or whatever) that's the best we can realistically hope for.

- "Time to market" matters.  A decent spec soon will have a lot more
beneficial effect on industry practice than a great spec somtime in the
unknown future.     

- Politics and personalities can delay things horribly. Tim says of the
XLink WG (which he once chaired) "a combination of factors including
personalities caused it to waste literally years at a time."  We each need
to be wary of the temptation to focus on personal  battles rather than the
overall war against chaos.  

- Evolution beats revolution, even if existing practice is not all that
strong a foundation to build on.  As Tim puts it (in the TAG posting pointed
to above) "HTML hyperlinks changed the world, even though they are
metadata-light, single-ended, and without builtin indirection."