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

[Rachel Foerster <rachelf@ix.netcom.com>]

Fred,

OK, now I see your point....I guess I'm a bit dense. And now that I see it,
I can agree with it! How 'bout that!

Rachel

-----Original Message-----
From: Fred Blommestein, van [mailto:f.van.blommestein@berenschot.com]
Sent: Monday, April 22, 2002 11:08 PM
To: rachelf@ix.netcom.com; 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...


Rachel,

You may differ with me, I don't with you.
I also want it in a processable way AND in a viewable way. That's why XML
was invented. I want the flexiblity at the receiver's side to set the level
of integration without bothering the sender.
ebXML IMO doesn't support that (yet).

Fred

<<< "Rachel Foerster" <rachelf@ix.netcom.com>  4/23  1:37a >>>
Fred,

This is where you and I differ....I want the data in a processable format. I
don't want to look at it on my monitor. Until I can get it this way I'll
continue with good old fashion paper. Even though I could go to various web
sites to look at account details, etc., I don't because it's not convenient
to the way I want to work.

BTW, however, I do pay everything (and I mean everything...except my dry
cleaner) with either AMX or via electronic payment through Quicken to
CheckFree. No more checks/paper/cash!

So....no right or wrong here....but herein lies a challenge....what DO these
SME's want?

Rachel

-----Original Message-----
From: Fred Blommestein, van [mailto:f.van.blommestein@berenschot.com]
Sent: Monday, April 22, 2002 4:06 PM
To: rachelf@ix.netcom.com; 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...


Rachel,

I agree, that ultimately I would like to do everything automatically through
my Quicken system. But what if Quicken (or whatever accounting system I
have)  does not support that (yet). Or doen't support that specific document
or process.

And you are wrong. I don't want merely to see the message on my monitor, I
want to be able to retrieve more information if needed and give a response
as well (and in the process I want my Quicken system to get the data it
needs).

Anyway what I need is a more flexible way of communication than receiving an
electronic document that is a copy (but less readable) from the paper one.

Fred

<<< "Rachel Foerster" <rachelf@ix.netcom.com>  4/22 10:49p >>>
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>




----------------------------------------------------------------
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>