[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. 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:firstname.lastname@example.org] > Sent: Monday, April 22, 2002 3:41 PM > To: email@example.com; firstname.lastname@example.org; > email@example.com > Cc: firstname.lastname@example.org; email@example.com > 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
Powered by eList eXpress LLC