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

[bhaugen <linkage@interaccess.com>]

What I got from Fred's message is the idea of a
turnaround document, for example a PO that
turns into an advanced shipping notice.
Whether one sees it in a Web browser
or Quicken (or Quicken in a Web browser)
seemed to be secondary.  Or to put it another
way, think of the turnaround document
as a cheapo business process.

I agree with the need for an ebXML-Quicken plug.

-Bob Haugen

----- Original Message -----
From: Rachel Foerster
> 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