Re: What do people really expect from ebXML? - Whatever it is,itbetter be easier than EDI

[David Powell <david@xactcommerce.com>]

William in arguing his point, makes my point better than I had hoped to do
myself.

"William J. Kammerer" wrote:

> And what did he mean by "rate"?  Actually I had no idea, but since he
> omitted "unit price," I made another assumption that "rate" was a
> synonym of "unit price."  Was the tax a rate or an amount?  Since he
> didn't explicitly say rate, I made another assumption.  Can I always
> expect the quantity * unit price + tax = amount, or are there some other
> assumptions and tricks?  Was Lyon's "description" really a product name,
> as I assumed?  What were his "comments"? I didn't say yesterday, but I
> assumed that it must've been an extended product description, even
> though it could just as easily have been shipping and handling
> instructions!
>
> This is a lot of assumptions to make, and just for a simple invoice line
> item.  The only way to be sure we're talking about the same things is
> for David to do a better job of documenting, or for me to call him up,
> where we both lose all solution scalability if we have to do that with
> each and every trading partner.

Wow.  and that's just the beginning.   But if you think David is going to
do such a poor job of documenting what his values "mean".. lets substitute
a one size fits all approach to make this easier?
We are then proposing that all must go and find the common definitions and
compare these elements to the ones they take.. and if these elements are
different.. well.. then folks need to design their transactions to conform
to some standard form of that transaction to meet this specific definition.

At least I can call David or send him an email.. I won't really be able to
do that with ebXML.org. Why should they care about David Lyons and my puny
problems if their system doesn't fit our needs?
If this solution worked.. there would be only one accounting system and
ebXML wouldn't need to be discussed.  Don't look now.. perhaps this is
Microsoft's next offering.  But otherwise, people spend insane amounts of
money on accounting systems because "one-size-fits-all" just doesn't work
for business.

There are two ways to approach finding what works.  Think it up.. and make
everyone do it till they get disgusted.  Or allow folks a process to
construct what they need and build on what others have built, and perhaps
they will be confused and struggle, but if the tool is good, so is the
outcome.  When Java first came out it was slow, there were virtually no
class libraries and it was cool, but mostly useless.   Six years later, and
darn.. now it is fast and way cool and very useful.  It comes with a core
(SDK) that mostly wasn't there at the beginning that facilitates the
development of ever more capable extensions.  ebXML could be a language
like this.  Doing things we don't dream of now.. but how this core is
done.. will determine this ability to morph into something useful or make
ebXML just another product of committee reasoning.


> Sue Probert's business about "fixing semantic anchors" with UUIDs, or
> some other artifact like normalized labels from the BSR or BSI/BEACON,
> is necessary so I can be sure Lyon's "description" is the same as my
> "product name."

Directories of this information are quite appealing.  But are vulnerable to
the same fight to identify the basic "semantic anchors."  Still, the real
problem with any centralized system is that this centralization is an
almost unacceptable concentration of control or risk to business
operations.  Control the directory and make it mandatory and now you can
make everyone pay a tax to whoever "owns" this directory or leave doing
business..  EDI does not have this vulnerability no matter how much folks
slam on it.

EDI is difficult because:

*One way packet based data transfers

Bureaucratic Data Mapping and Control checks that are not obvious.

*Rigid definitions and structures that do not facilitate evolving
communications between parties.

on and on..

ebXML promises:

*Interactive exchange of transactions (real time)

*Potential for Mapping to be interactive and based on a public interface of
some sort - whether that is a UUID db listing or some such source (or as I
would prefer, an interface published by the trading partner which provides
available "transactions", "elements", and definitions and even formulas if
necessary.)  But, this is just a matter of form.. not substance.  In this
world, one player can accommodate the other at their own leisure, where as
with EDI it is a dance of phone calls and frustration.  Opposite to ebXML,
the EDI mappings are in a book on some shelf.

*Potential for extensible interaction rule making by the parties.

I just think its the height of arrogance to believe that someone can draft
the language of "business" any more than Esperanto can tomorrow be
legislated as the world's spoken/written language.  Life sure would be
easier if we could, but it isn't going to be mon ami.

Look, I really feel off base poking my nose into this.  Folks are working
hard at getting something done.  I just want the folks who were talking
about making the core "lego" blocks rather than this definitional (in my
mind) nightmare have my imagination.  I am ready willing and able to be
happily suprised.

But I also see ebXML being adopted on the margins and growing to
acceptance.. some folks would rather force this.  I guess its just choosing
the sort of world you want to live in.

David