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] Article on ebXML Core Components...

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.
> certainly doesn't get at the need to be able to automatically take the
> into a system.
> As an SME I don't want to view the message, I want to take the data
> 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
> Todd, others,
> I always understood that the added value of XML over EDI is that you
> send XML to a simple browser, while for EDI you need expensive
> Yet the focus of ebXML seems to be a mere replacement of EDI, with
> middleware, but only more complex.
> In my view ebXML will only be viable (but then very viable) if support
> it is built in in operating systems and general utilities like
> To enable that, we should:
> - define a message service layer that is handled by (next version)
> (and mobile phones)
> - define browser (and mobile phone) compatible "patterns" or
> A browser compatible "pattern" takes into account that a message (that
> crowded with non human readable codes) is not just sent to the other
> but that the receiver (or his stylesheet) may decide what information
> 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
> Any thoughts?
> Fred van Blommestein
> Berenschot - EP-NL - OpenXchange

[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