Doug
My intent, in comparing the traditional EDI with Internet EDI was to
highlight the subtle gap between these two.The gap ofcourse is not that big,
that it cannot be filled.
What is a VAN after all? It is nothing but an ISP if the gaps are
filled.Like an old wine in a new bottle.
Ashwani
>From: Doug Anderson <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: RE: The need for speed: XML vs. Internet EDI
>Date: Wed, 19 Jul 2000 12:13:00 -0500
>
>Ashwani
>
>Interesting insights, but I can't say that I agree with some of your
>conclusions on how internet EDI is different from traditional EDI. The
>internet is just a another transport mechanism.
>
>1. We (Kleinschmidt) support any protocol. Therefore the sender or
>receiver of the data is not tied down to any one means of communication.
>We
>support TCP/IP if the customer wants it. With the internet, if the ISP
>goes
>down you are hosed, unless you have multiple ISP's (like we do). With a
>VAN, if your ISP goes down you can still use the old "legacy" means of
>communication like Xmodem, or Zmodem. Most VANs support multiple
>protocols,
>you would have to check with your specific VAN to see if they support the
>communication method that you would like to use.
>
>2. Delay, interesting comment. We don't delay data here at Kleinschmidt,
>unless the customer would like us to deliver or pick-up data on a scheduled
>service. And many do and that is a service we provide.
>
>We have 4 state of the art Tandems in production with a fifth being
>installed as we speak. We have two production sites with multiple phone,
>ISP's, power supplies with different voltages, UPS (battery back-up not the
>motor carrier), diesel generators etc. so that we have what we think is the
>highest reliability in the market. Vs. the internet, depends on the means
>of communication. Communication over the internet where you get an
>immediate acknowledgment is good for time sensitive data, but if you have a
>problem who do you call? Using email can be very sporadic, sometimes fast,
>sometimes you can get a message back hours later that your message can't be
>delivered for hours.
>
>Note that my earlier post to this message board was delayed from yesterday
>afternoon to this morning, so I reposted. Problem could be anywhere in the
>chain. A process must be in place with each trading partner, defining what
>to do if you don't get the acknowledgement back after sending the data.
>Don't forget that timing of the acknowledgement's return can be different
>for each trading partner. And if that process takes place after normal
>business hours does, your company (and your trading partner and ISP) have
>someone available to monitor that process 24 x 7? We monitor each of those
>items (and so do some other VAN's).
>
>3. Cost of communication. How do you reach the internet? Do you have
>some
>magical way of getting the data from your computer to the ISP or do you use
>some type of communication line? Sounds to me like the cost for the
>physical communication method is very similar. Don't know about local or
>not. Here in Illinois businesses have to pay for local calls like long
>distance calls, but the long distance is cheaper. On top of that you can
>reach customers (suppliers) via a VAN that want to use the internet and
>those that don't want to without having multiple processes running.
>
>4. Basically correct. You do pay for service. And you generally get what
>you pay for. How many folks own a car, maybe a Lexus, Mercedes, or
>something similar with leather seats and power windows, vs. a Yugo or KIA.
>Both the Yugo and KIA will get you to the same destination, for a lot less
>money, but is the reliability the same. What about the service you receive
>when there is a problem? Your decision on the car, your decision on cost
>vs. service.
>
>5. I won't specifically comment on this one since we don't sell software.
>However, we do provide "in-network" or "outsourced" translation for many of
>our customers. This is platform independent and saves our customers money.
>We already are doing XML translations for customers. Those customers did
>not need to change anything on their side in order to communicate via XML
>vs. "traditional" EDI.
>
>6. My personal opinion. XML is EDI. It is a means of formatting data
>that
>is being transmitted between two something's, where the something's can be
>applications, people or whatever. It (XML) has its advantages and
>disadvantages, depending on the application. XML is certainly more web
>browser friendly, but as for moving data from application to application
>via
>the internet I am not sure that it provides all the advantages sometimes
>touted here.
>
>Doug
>
>Doug Anderson
>Assistant Vice President Sales Support
>Kleinschmidt Inc.
>450 Lake Cook Road
>Deerfield, IL 60015
>847-405-7457
>847-458-5234 (home office)
>847-945-4619 (fax)
>mailto:[EMAIL PROTECTED]
>http://www.kleinschmidt.com
>
>
>-----Original Message-----
>From: ashwani madan [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, July 18, 2000 6:05 AM
>To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: The need for speed: XML vs. Internet EDI
>
>
>Hi Steve,
>
>I agree with discussion group members that XML won't make much of a
>difference in transmisson time,because XML means just a syntax/format
>change.Adding information about the data itself (meta data) anyways flows
>with conventional EDI as well, in terms of tags/codes.XML is a means to
>provide easy and efficienct data processing capabilities.
>
>Just an insight, how Internet EDI is different from conventional EDI is
>summarized as below :
>
>1.Traditional EDI :-* VAN based. Uses proprietary protocols.
>Internet EDI :- Internet based. Uses TCP/IP protocol
>
>2.Traditional EDI :-* Offline - Delay in delivery
>Internet EDI :- Online - Instant delivery
>
>3.Traditional EDI :-* Expensive if VAN is not local.May have invest in
>ISDN,Dialup,Leased Line,etc. to reach the VAN network
>Internet EDI :- Can be reached through normal Internet connection.
>
>4.Traditional EDI :-* Billing is generally by character or transaction.
>Internet EDI :- Flat monthly fee (based on pipe bandwidth or connect time).
>
>5.Traditional EDI :-* EDI Softwares are not Platform independent. There has
>to be a different version for installation on different OS e.g., Unix,
>windows etc.
>Internet EDI :- Platform independent
>
>6.Traditional EDI :-* EDIFACT, ANSI X.12, TRADACOMS, etc are conventional
>EDI standards
>Internet EDI :- XML is Internet oriented. Other conventional EDI standards
>can be easily wrapped in XML.
>
>Ashwani
>
>
>
>
>------ XML/edi Group Discussion List ------
>Homepage = http://www.XMLedi-Group.org
>
>Unsubscribe = send email to: [EMAIL PROTECTED]
>Leave the subject and body of the message blank
>
>Questions/requests: [EMAIL PROTECTED]
>
>To receive only one message per day (digest format)
>send the following message to [EMAIL PROTECTED],
>(leave the subject line blank)
>
>digest xmledi-group your-email-address
>
>To join the XML/edi Group complete the form located at:
>http://www.xmledi-group.org/xmledigroup/mail1.htm
>
>
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
