RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components...

["Schneider, David" <David.Schneider@iona.com>]

The question I have as a vendor of solutions in this space is what a SME would pay for a complete solution...software, hardware, and Services to install a package to allow you to do exchange data with 1-2 of your largest trading partners (the people asking you to do this in the first place)?

This data will allow companies like mine to build the correct solutions for the market!

Thank you for your help!

David

-----Original Message-----
From: Rachel Foerster [mailto:rachelf@ix.netcom.com]
Sent: Monday, April 22, 2002 1:47 PM
To: 'Fred Blommestein, van'; mike@rawlinsecconsulting.com;
tboyle@rosehill.net; ckharvey@zaratechnology.com.sg
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components...


Fred,

Your concept seems to me to be one of requiring the receiver, i.e., the SME,
to have to deal with the business message as a display on a monitor. That
certainly doesn't get at the need to be able to automatically take the data
into a system.

As an SME I don't want to view the message, I want to take the data into
Quicken! I want to view it only after it's in my application system and then
make business decisions, such as whether to post or not and then pay or not.
A big difference.

Rachel

-----Original Message-----
From: Fred Blommestein, van [mailto:f.van.blommestein@berenschot.com]
Sent: Monday, April 22, 2002 3:41 PM
To: mike@rawlinsecconsulting.com; tboyle@rosehill.net;
ckharvey@zaratechnology.com.sg
Cc: rachelf@ix.netcom.com; ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components...


Todd, others,

I always understood that the added value of XML over EDI is that you can
send XML to a simple browser, while for EDI you need expensive middleware.
Yet the focus of ebXML seems to be a mere replacement of EDI, with expensive
middleware, but only more complex.

In my view ebXML will only be viable (but then very viable) if support for
it is built in in operating systems and general utilities like browsers.

To enable that, we should:
- define a message service layer that is handled by (next version) browsers
(and mobile phones)
- define browser (and mobile phone) compatible "patterns" or transactions.

A browser compatible "pattern" takes into account that a message (that is
crowded with non human readable codes) is not just sent to the other end,
but that the receiver (or his stylesheet) may decide what information he
needs to retrieve additionally from the sender to take the next step.

So the "logical" transfer (e.g. send a purchase order) may behave
technically as a dialog, resulting in the same commitment.

The challenge is to let this be transparent for the sender, who doesn't know
(and doesn't care) whether the message goes to an SME or a multinational.

Any thoughts?

Fred van Blommestein
Berenschot - EP-NL - OpenXchange

<<< Todd Boyle <tboyle@rosehill.net>  4/22  9:59p >>>
Me too.

Mike Rawlins wrote:

>Excuse me, but I can't help but violently disagree with most of this
>sentiment!
>[...]
>We need better solutions, not bigger sticks...
>
>Christopher Harvey wrote:
>
>>...my 0.02 cents worth is to ask all involved to understand
>>   the needs of the SMEs but to use the big guys to force change.

Here's one idea: a bettor's approach, or a PicoIPO:


Dear SME Accounting Software vendor:

I hereby offer to pay you to build a UBL interface on your
product.  You will offer it for sale to your users.

Together we will calculate how many unit sales it requires
for you to recover the cost of the development.  You will
repay me for my investment at a flat rate until you reach the
breakeven sales.  Then you will pay me another $1000
winnings, from any further incremental sales.  Then you
can keep the sales proceeds after that.

Stop arguing which came first, the chicken or the egg.

Here is an egg.

Todd


----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>




----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>