[
Lists Home |
Date Index |
Thread Index
]
Joseph Chiusano wrote:
> I have a theory on the subject of "competing
> specifications" that I'd like to present,
It is almost a truism that competition is a good thing whether
it be in the marketplace for goods (beans), ideas (memes) or species
(genes). The general experience of competition is that it results in
progress or "betterment" of one form or another in whatever realm the
competition occurs. However, this is not always the case. As we
regularly learn, some forms of competition are less useful and less
good or "productive" then others...
Competition in the standards world spans multiple
marketplaces. It occurs within the realm or marketplace of both goods
(products that can be built) and ideas (methods for building them).
Competition in the standards world is also closely tied to the
survivability of "species" (i.e. companies or consortia) that take one
position or another in the standards battle. The problem here is that
what is a "victory" or an "advance" in one realm is often a regression
in another... In the standards world, competition often ends up
focusing on the a battle between companies, rather than the battle
between ideas.
The flury of WS-* standards, many of which are competitive
treatments of the same or related subject, is a good example of
less-then-optimal competition. Take, for example, the trio of
WS-Eventing, WS-Events, and WS-Notification. These three
specifications, all put forward by different companies or consortia
(with some overlapping members...) are, at their core, very similar.
There is a basic common "idea" that is being presented in this group
of specs -- that we should have a protocol for event-based systems.
There is also a great deal of agreement between the three efforts on
what the elements of that protocol should be. However, they differ on
specifics. In some cases, the difference is purely syntactic and thus
not substantive (i.e. similar elements with identical semantics are
given different names in competing specs). In some cases, the
differences are semantic. But, if you put aside syntax, these specs
agree more than they disagree. They are largely equivelants.
In an ideal world, the three forces supporting different
visions of the basic idea behind these "event" specs would agree to
agree on the things that they agree on and then lead fierce "battles
of ideas" over those elements that they don't agree on. The result
might be that one group is convinced by the arguments of the other or
that a means is found to allow multiple solutions to be deployed
within a common framework.
But, that is not the way that is being pursued here. While one
would hope that these standards battles are primarily battles of
ideas, what we have instead is battles between companies. The question
here is which *company* or consortium will win, not which is the best
way to implement an event based protocol. Thus, what we've got is
competition of between species (companies) rather than competition
between ideas. The result will not necessarily be a victory of the
best ideas.
A battle between equivelants in the standards world leads to a
victory for one group over another. This is very different from a
battle of equivelants in the marketplace for goods and services. In
normal economic competition, a battle between equivelants will
normally lead to a reduction in price which, at least, benefits
consumers. However, we get no such "collateral" benefits from a battle
of equivelants in the standards world. Consumers don't benefit from
either side "winning." Yet, they pay by having to subsidize the costs
of the battle through increased prices, often a reduction in the
number of providers, as well as reduced innovation.
It is my experience that in the standards world, competition
between ideas is a wonderful thing, but competition between
specifications is very often a "bad" thing. The problem is that when
you have competing specs, the focus becomes more on *who* made a
proposal rather than on *what* was proposed. It would be better if we
encouraged competition between "parts of specs" (i.e. the ideas)
rather than competition between entire specs.
bob wyman
-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Friday, April 02, 2004 11:20 AM
To: xml-dev@lists.xml.org
Subject: [xml-dev] Competing Specifications - A Good or Bad Thing?
I have a theory on the subject of "competing specifications" that I'd
like to present, in hopes of getting some good feedback. I'm thinking
mostly in terms of Web Services specifications - or specifications
that are not intended strictly for Web Services by nature, but have
applicability to Web Services.
By "competing", I mean 2 or more specifications that cover the same
"functional area" (e.g. reliable messaging, context, transactions,
etc.) and most/all of the same general actions that are applicable to
that functional area (e.g. for reliable messaging, "notify a sender
reliable messaging processor that a message was received
out-of-order"). Some examples of such overlapping specifications (both
"open" and emerging) would be:
* Reliable Messaging: OASIS WS-Reliability, WS-ReliableMessaging
* Transaction/Coordination: WS-Transaction (WS-AT and WS-BA), OASIS
WS-CAF
* Identity Management: Liberty Alliance, OASIS SAML 2.0
My theory: Competing specifications are not necessarily a bad thing,
as long as:
(1) The cost to an organization to interoperate with another
organization (or another system within the organization) that
implements a competing specification in a given functional area is
either minimal or 0, and
(2) The risk is either minimal or 0
One case in which the risk would (in my opinion) be more than minimal,
and possibly quite high, would be in reliable messaging:
WS-Reliability, for example, considers a message ID to be a unique
combination of [a Group ID + a Sequence ID]; if an organization that
implemented WS-Reliability were, for example, to interoperate with an
organization that implemented a reliable messaging standard that did
not group message IDs together (but instead used unique message IDs
for each message), a middle process would be required to pack/unpack
groups of messages between the installations as required. If this
"translation" were to be faulty (due to a software or configuration
bug), the whole messaging interaction could be - pardon the pun -
unreliable.
Thoughts? Comments?
--
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>
|
