OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [ebxml-dev] RE: [EDI-L] Announce - Latest Article on ebXML


I really have no model of why a technology fails
or succeeds in making it into products in specific
markets at certain times. However, I am very
suspicious of the kind of argument you are
supplying about the history of X12 838 and how 
that extrapolates to ebXML CPPA. 

If I were to accept your pattern of argument, 
I would also have to accept the argument that the failure
of videotex in the U.S. would predict that
internet browsers should have been a complete fiasco! 
I don't think very many people are going to buy
such a weak pattern of inference.

I personally think it would be fairly complicated
to explain why videotex failed here (but not in France)
but eventually something vaguely similar (browsers) succeeded
wildly. The question then would be
whether the X12 838 is to videotex as
ebXML CPPAs are to browsers, or instead, whether
the X12 838 is to snakeoil as ebXML CPPA
is to snakeoil (snakeoil always has had 
some adherents, but not a "critical mass").

I think it is worthwhile to recall some
specifications where an ability to exchange
capabilities did make it into products having
on any definition a "critical mass": PPP handshake,
SSL/TLS handshake, the HTTP Accepts header, modem negotiation
routines, and so on. In other words, the key functionality
that CPPA technology embraces-- exchange of capabilities
for collaboration-- has some track record of being
successful. (It is worthwhile noting that the 
bulk of an 838 is what the CPPA handles under
its PartyRef element, information largely outside the CPPs
or CPAs real point, and is actually pointed to by a URI.
There is really very little similar functional similarity
between the 838 and the CPPA specifications.)

Current standards involving capabilities on which the
verdict is out or pending: IETF CONNEG, MPLS, SAML, RDF, 
ICE, WSDL, CPPA, XAML, BEEP profiles, etc, etc.
Which ones will be like modem negotiation and become
part of the infrastructure, happily making things easier
while becoming more and more automatic? Which
will become dusty specifications? The verdict just is
not in yet.

My point against your analysis remains: 
Arguments with the pattern:
"Because there was once 
a technology that seems to someone 
to be vaguely similar to technology X 
and that this previous technology failed to be
adopted at a particular time,
that therefore technology X won't be adopted ever."
are not arguments with a reliable pattern of inference.

As far as the market goes, if the products
incorporating profile technology have superior
ROI, the point may not be lost on those who are
building new systems. Then again there are better
mousetraps that never gained market acceptance.

-----Original Message-----
From: Mike Rawlins [mailto:mike@rawlinsecconsulting.com]
Sent: Monday, November 26, 2001 12:59 PM
To: Dale Moberg
Cc: bhaugen; rachelf@ix.netcom.com; edi-l Yahoo List; ebxml-dev
Subject: Re: [ebxml-dev] RE: [EDI-L] Announce - Latest Article on ebXML

Ah, finally someone seriously challenging my analysis!   :^)

Dale Moberg wrote <snipped>:

> Also, looking at the article at the end
> of the referenced URL, which is a tad
> negative by the way, there is a comparison of
> CPPs and CPAs with X12 838s. I think
> that is also a serious misunderstanding
> of why CPPs and CPAs might be valuable
> in terms of ROI. The CPP and CPA stuff
> can reduce the configuration
> time involved in adding another
> business collaboration participant,
> and do it interoperably.
> It would thereby reduce the labor costs associated
> with adding new collaborations. That may
> not be important to a business that
> only collaborates with 1 other business.
> But it might be important to businesses
> with, for example, 50 or more collaborators
> by reducing average
> start up time from weeks to hours.

Hmm...,  I don't see the misunderstanding.  I think that's exactly what
thought I said.  Certainly the negotiated CPA has a lot more useable
information than the X12 838.  And yes, if you have 50 trading partners
have a much better chance of getting a positive ROI than you do with
My point is that, even as limited as the 838 is when compared with the
CPA/CPP, it could still be very helpful if you have 50 trading partners
an EDI environment.  That no major EDI software vendor has implemented
should tell us that the market has expressed little demand for this type

Michael C. Rawlins, Rawlins EC Consulting

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC