[
Lists Home |
Date Index |
Thread Index
]
personal view (possibly jaded) - competing specs are by and large bad.
competing companies to meet the specs are by and large good.
any number of examples, but programming languages are as good a place as
any to look. cobol, sql, html are all languages/technologies whose
usefulness and market penetration soared with standards and competing
vendors.
c is possibly a counter example. though more correctly a good example of
what happens when a de facto standard differs in some significant ways
from a de jure standard.
the other lesson remains that standards that codify practice are much
more useful than standards that try to drive practice. simply because
codifying practice is codifying what works. the rest is really just
polemics.....
rick
On Sun, 2004-04-04 at 03:11, Bob Wyman wrote:
> 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?
|
