I have to agree that standards are available, and have been implemented for
sending EDI securely without going through a VAN. In the natural gas
industry, we've developed a mechanism that uses PGP, and it's worked quite
well. For next year, we have decided to go to EDIINT AS2, which provides
for either PGP or sMIME encryption of the EDI message.
Andy
---------------------------------------------------------------------------------------------------------------------------
James Bertsch <[EMAIL PROTECTED]>@LISTSERV.UCOP.EDU> on 10/26/2000
10:42:41 AM
Please respond to James Bertsch <[EMAIL PROTECTED]>
Sent by: Electronic Data Interchange Issues <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: EDI-L Digest - 23 Oct 2000 to 24 Oct 2000 (#2000-242)
It is true that EDI nor XML solve the problem of sending secure data over
the Internet.
But, there are other standards that do this using EDI or XML. In the
telecom industry we are starting to move away from VANS because we have a
Public Key Infrastructure (PKI) standard for transmitting information. The
bottom line
is that VANS are expensive and unnecessary in todays high bandwidth
Internet.
The PKI standard that we use is called Interactive Agent. It is designed
to
use SSL 3 and RSA's digital signature
technology. Not only is every EDI document encrypted while going over the
Internet, but a digital signature
can be placed on every EDI document guaranteeing nonrepudiation -- i.e.,
the
document can be taken into a court of
law and enforced in the same way as a hand signature on a paper document.
In terms of performance, it is fast -- Sending 10,000 EDI documents a day
is
not a problem (with the right hardware of course). It can probably go way
beyond that, but I have never done any real stress testing to determine the
limits.
It seems to me that it is time for every industry to get together and
develop a cross industry standard for PKI that everyone can use.
Jim Bertsch
Mantiss Information, A Dynegy Company
200 N. LaSalle suite 2450
Chicago, IL 60601
[EMAIL PROTECTED]
-----Original Message-----
From: Automatic digest processor [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 25, 2000 2:00 AM
To: Recipients of EDI-L digests
Subject: EDI-L Digest - 23 Oct 2000 to 24 Oct 2000 (#2000-242)
IThere are 15 messages totalling 3082 lines in this issue.
Topics of the day:
1. XML for EDI book: Any comments? (11)
2. Test & Development Liscense (2)
3. Sterling 6.x changes (was: [Fwd: In response to Kayla])
4. Looking for some help.
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
----------------------------------------------------------------------
Date: Tue, 24 Oct 2000 07:16:15 -0400
From: "Glass, John K. III" <[EMAIL PROTECTED]>
Subject: XML for EDI book: Any comments?
Hello group.
I was browsing through some books at amazon.com and noticed a book that's
supposed to be coming out in November called:
Xml for Edi : Making E-Commerce a Reality
by Hussain Chinoy, Tyna Hull, Robi Sen
I was wondering if anyone has preordered this book and if you have
heard any buzz about what it will contain. You guys don't know of any
other
books which dealt with this whole EDI/XML issue, do you? Anyway, any info
that you have about this book would be appreciated.
Thanks.
------------------------------
Date: Tue, 24 Oct 2000 08:22:15 -0500
From: "Coffey, Patty" <[EMAIL PROTECTED]>
Subject: Test & Development Liscense
List-
I am in urgent need of feedback regarding costs for T&D liscences. I am
being charged an extremely high dollar amount (half of list) for a T&D
lisence. After researching our other top tier in house apps, I discovered
that we don't pay for the T&D lisence on any of them.
Is it standard to charge some fee for these? It would seem to me that
providing a T&D lisence is part of doing business. Do software vendors
expect us to do testing and development in a production environment or pay
to ensure that we don't blow anything up.
In my experience, I have found that I am doing more QA on the vendors
product than anything else.
Any input is greatly appreciated.
Patty Coffey
Manager, e-Commerce
ACCO Brands, Inc.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Phone (650) 572-2700 ext. 3355
Fax (650) 572-9579
2000 laptops will be stolen today, make sure yours isn't one of them!
Use the MicroSaver by Kensington - go see it at www.microsaver.com
------------------------------
Date: Tue, 24 Oct 2000 09:50:40 -0400
From: "Hurd, Richard A (Rich)" <[EMAIL PROTECTED]>
Subject: Re: Sterling 6.x changes (was: [Fwd: In response to Kayla])
> What in the world are you doing with 1,000 Mentor maps?
> I've been in some very large EDI shops and have yet to come across any
> more
> than 100 maps.
>
We're not very big, but you can't have forgotten that quickly... ;-{)
122 /opt/edi/maps> ls *.map | wc -l
228
> I can't imagine a business scenario that requires that many maps. Please
> elaborate.
>
> On the original thread, what are our alternatives? Seems like 5 years is
> reasonable to keep the existing lftran program alive if their
> are overall benefits to the new architecture. Having never used the NT
> version of the mapper, I hear it is more robust than it's UNIX
> counterpart.
> However, I'm still batting for keeping the core server tools in UNIX.
> Where
> are you going to get so much flexibility and portability?
>
That's all well and good except for this as-yet unanswered question:
Will they sunset the old version of the standalone mapper before the 5 year
window closes? You know that's what everybody will end up doing, and it's
exactly what Sterling won't want them to do -- they'll deploy the
standalone
mapper on the developers' PCs (if they have PCs, that is) and continue
making changes to the "legacy" maps instead of the alternative. And
remember what the alternative is: you will not be able to modify the maps
at
all. No changes whatever unless you make the supreme effort to recode the
whole thing.
I guarantee that when the final release comes out, the use of the
standalone
5.x mapper to support "legacy" maps will be an "unsupported" configuration.
It behooves Sterling to force people to change, but Newton's law of inertia
obtains here.
Frankly, after staring in horror at each version of the mapper that has
come
out, I relish the chance to use anything else. LOL
------------------------------
Date: Tue, 24 Oct 2000 09:50:55 -0400
From: Alan Kotok <[EMAIL PROTECTED]>
Subject: Re: XML for EDI book: Any comments?
John, et al.
Dick Raman, CEO of EDI-TIE wrote a book on XML/EDI last year. I believe it
was self-published.
Alan Kotok
Director, Education and Information Resources
Data Interchange Standards Association
[EMAIL PROTECTED]
+1 703-518-4174
** DISA's E-Business and Internet Conference, 7-9 March 2001, in San
Francisco.
http://www.disa.org/conference/annual_conf/index.htm **
At 07:16 AM 10/24/00 -0400, Glass, John K. III wrote:
>Hello group.
>
>I was browsing through some books at amazon.com and noticed a book that's
>supposed to be coming out in November called:
>
>Xml for Edi : Making E-Commerce a Reality
>by Hussain Chinoy, Tyna Hull, Robi Sen
>
> I was wondering if anyone has preordered this book and if you
have
>heard any buzz about what it will contain. You guys don't know of any
other
>books which dealt with this whole EDI/XML issue, do you? Anyway, any info
>that you have about this book would be appreciated.
>
> Thanks.
>
>=======================================================================
>To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
>To subscribe, mailto:[EMAIL PROTECTED]
>To contact the list owner: mailto:[EMAIL PROTECTED]
>Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
------------------------------
Date: Tue, 24 Oct 2000 09:09:08 -0400
From: Lee LoFrisco <[EMAIL PROTECTED]>
Subject: Re: XML for EDI book: Any comments?
I'm a bit confused about the benefits of XML. In a traditional
EDI-intensive shop, where the supply-chain, time-critical documents
are communicated electronically, and at a huge savings, where would XML
improve this process? Granted, when communicating between a web site and
desktop, XML has found a home. Entering a purchase order via a web-based
entry screen, applying edits, and submitting the info to an ERP system is a
practical, cost-effective method of order processing for non-EDI orgs.
But,
at some point along the way from entry to placing the order, the XML file
needs to be translated to EDI (or some standard) before updating or else an
org would have to maintain an endless list of unique *maps* to accommodate
all the variations. Now, that sounds like EDI to me.
Without standards, which VP or Director is going to stake his or her career
on recommending changing from traditional EDI to XML? With millions of
dollars invested in effort and resources with EDI, and with the documents
flowing, why change? XML builds larger files and has yet to prove itself.
If it ain't broke, don't fix it!
Why all the hoopla about XML vs. EDI (unless of course it's from the XML
software developers themselves)?
Lee LoFrisco
Sterling Commerce Service Partner Consultant
VoiceMail: 614.210.2706
Cell Phone: 410.963.6218
eFax: 810.277.5002
-----Original Message-----
From: Electronic Data Interchange Issues
[mailto:[EMAIL PROTECTED]]On Behalf Of Glass, John K. III
Sent: Tuesday, October 24, 2000 7:16 AM
To: [EMAIL PROTECTED]
Subject: XML for EDI book: Any comments?
Hello group.
I was browsing through some books at amazon.com and noticed a book that's
supposed to be coming out in November called:
Xml for Edi : Making E-Commerce a Reality
by Hussain Chinoy, Tyna Hull, Robi Sen
I was wondering if anyone has preordered this book and if you have
heard any buzz about what it will contain. You guys don't know of any
other
books which dealt with this whole EDI/XML issue, do you? Anyway, any info
that you have about this book would be appreciated.
Thanks.
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
------------------------------
Date: Tue, 24 Oct 2000 08:53:53 -0500
From: Scott Maxwell <[EMAIL PROTECTED]>
Subject: Re: Test & Development Liscense
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C03DC1.D88FC1BA
Content-Type: text/plain;
charset="iso-8859-1"
Patty:
I was told that I too would have to pay for a Test and Developement license
if I wanted a test environment on Harbinger's TLE EV5. I truly wish that
Peregrine would step up and confront their number one concern, the
customer.
Scott Maxwell
E-Commerce Administrator
The Flexitallic Group
phone: 281-604-2454
[EMAIL PROTECTED]
-----Original Message-----
From: Coffey, Patty [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 24, 2000 8:22 AM
To: [EMAIL PROTECTED]
Subject: Test & Development Liscense
List-
I am in urgent need of feedback regarding costs for T&D liscences. I am
being charged an extremely high dollar amount (half of list) for a T&D
lisence. After researching our other top tier in house apps, I discovered
that we don't pay for the T&D lisence on any of them.
Is it standard to charge some fee for these? It would seem to me that
providing a T&D lisence is part of doing business. Do software vendors
expect us to do testing and development in a production environment or pay
to ensure that we don't blow anything up.
In my experience, I have found that I am doing more QA on the vendors
product than anything else.
Any input is greatly appreciated.
Patty Coffey
Manager, e-Commerce
ACCO Brands, Inc.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Phone (650) 572-2700 ext. 3355
Fax (650) 572-9579
2000 laptops will be stolen today, make sure yours isn't one of them!
Use the MicroSaver by Kensington - go see it at www.microsaver.com
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
------_=_NextPart_001_01C03DC1.D88FC1BA
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Test & Development Liscense</TITLE>
</HEAD>
<BODY>
<BR>
<P><FONT SIZE=3D2>Patty:</FONT>
<BR><FONT SIZE=3D2>I was told that I too would have to pay for a Test =
and Developement license if I wanted a test environment on Harbinger's =
TLE EV5. I truly wish that Peregrine would step up and confront =
their number one concern, the customer.</FONT></P>
<P><FONT SIZE=3D2>Scott Maxwell</FONT>
<BR><FONT SIZE=3D2>E-Commerce Administrator</FONT>
<BR><FONT SIZE=3D2>The Flexitallic Group</FONT>
<BR><FONT SIZE=3D2>phone: 281-604-2454</FONT>
<BR><FONT SIZE=3D2>[EMAIL PROTECTED]</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Coffey, Patty [<A =
HREF=3D"mailto:[EMAIL PROTECTED]">mailto:Patty_Coffey@KENSINGT=
ON.COM</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, October 24, 2000 8:22 AM</FONT>
<BR><FONT SIZE=3D2>To: [EMAIL PROTECTED]</FONT>
<BR><FONT SIZE=3D2>Subject: Test & Development Liscense</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>List-</FONT>
</P>
<P><FONT SIZE=3D2>I am in urgent need of feedback regarding costs for =
T&D liscences. I am</FONT>
<BR><FONT SIZE=3D2>being charged an extremely high dollar amount (half =
of list) for a T&D</FONT>
<BR><FONT SIZE=3D2>lisence. After researching our other top tier =
in house apps, I discovered</FONT>
<BR><FONT SIZE=3D2>that we don't pay for the T&D lisence on any of =
them.</FONT>
<BR><FONT SIZE=3D2>Is it standard to charge some fee for these? =
It would seem to me that</FONT>
<BR><FONT SIZE=3D2>providing a T&D lisence is part of doing =
business. Do software vendors</FONT>
<BR><FONT SIZE=3D2>expect us to do testing and development in a =
production environment or pay</FONT>
<BR><FONT SIZE=3D2>to ensure that we don't blow anything up.</FONT>
<BR><FONT SIZE=3D2>In my experience, I have found that I am doing more =
QA on the vendors</FONT>
<BR><FONT SIZE=3D2>product than anything else.</FONT>
<BR><FONT SIZE=3D2>Any input is greatly appreciated.</FONT>
</P>
<P><FONT SIZE=3D2>Patty Coffey</FONT>
<BR><FONT SIZE=3D2>Manager, e-Commerce</FONT>
<BR><FONT SIZE=3D2>ACCO Brands, Inc.</FONT>
<BR><FONT SIZE=3D2>[EMAIL PROTECTED]</FONT>
<BR><FONT SIZE=3D2>[EMAIL PROTECTED]</FONT>
<BR><FONT SIZE=3D2>Phone (650) 572-2700 ext. 3355</FONT>
<BR><FONT SIZE=3D2>Fax (650) 572-9579</FONT>
<BR><FONT SIZE=3D2>2000 laptops will be stolen today, make sure yours =
isn't one of them!</FONT>
<BR><FONT SIZE=3D2>Use the MicroSaver by Kensington - go see it at =
www.microsaver.com</FONT>
</P>
<P><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D</FONT>
<BR><FONT SIZE=3D2>To signoff the EDI-L list, <A =
HREF=3D"mailto:[EMAIL PROTECTED]">mailto:EDI-L-signoff-=
[EMAIL PROTECTED]</A></FONT>
<BR><FONT SIZE=3D2>To =
subscribe, &n=
bsp; <A =
HREF=3D"mailto:[EMAIL PROTECTED]">mailto:EDI-L-subscr=
[EMAIL PROTECTED]</A></FONT>
<BR><FONT SIZE=3D2>To contact the list owner: <A =
HREF=3D"mailto:[EMAIL PROTECTED]">mailto:[EMAIL PROTECTED]</A>=
</FONT>
<BR><FONT SIZE=3D2>Archives at <A =
HREF=3D"http://www.mail-archive.com/edi-l%40listserv.ucop.edu/" =
TARGET=3D"_blank">http://www.mail-archive.com/edi-l%40listserv.ucop.edu/=
</A></FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C03DC1.D88FC1BA--
------------------------------
Date: Tue, 24 Oct 2000 09:45:35 -0700
From: Mark Kusiak <[EMAIL PROTECTED]>
Subject: Re: XML for EDI book: Any comments?
--4200089-11519-972405935=:1504
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Language: en-USA
The real truth about the XML vs. EDI is that XML is
sexy. It's the newest thing to come down the pipe in
a long while. As far as performing "rip and read", it
has merits and incentives for cost reduction that can
be achieved very quickly.
Most PC workstations today have XML enabled browsers
or can be updated with them very quickly at next to
nothing in cost. That means that the XML data file
can be displayed on the browser and made available to
the direct user of the information without much
intervention between the gateway and the user. It has
the potential of getting data to the person who needs
it rapidly. This is a real advantage of XML and
should be exploited if that is the goal.
Where XML falls flat is in true business system
integration between two separate or remote computer
systems. The use of the new standards (I use this
term lightly as they are changing faster then you can
shake a stick) will require that an interface be
either built for the XML centered transactions or that
the existing EDI interface programs be modified to
handle the data provided. The second branch will be
the method by which the implementation of XML happens.
EDI has always been envisioned as the enabling
technology to allow information from one computer in a
company to be transmitted to another company,
translated, and loaded to that companies application.
All EDI affiliated professionals know that this is the
true crux of costs in accomplishing the "computer to
computer integration of information". XML has NOT
solved this problem, unless it's cheaper to hire a
clerk to sit, gather, and plug in what he/she sees on
the browser (I feel that this is a huge step
backwards).
Most XML pundits believe that EDI cannot be
communicated over the NET. Most managers believe the
same thing. THIS IS FALSE. EDI data will go just as
fast as XML data. The problem which has not been
solved by either standard is that the data (invoicing
and ordering) must be secure between the two
companies. Not just the firewall, but the transmitted
file of data moving across the nodes on the WEB. This
means that a fast and reliable encryption must be used
to ensure that the data is not sniffed in the middle.
XML's promise of reduced communications costs are
given at the sacrifice of security. Communications
via a VAN allow me to have an organization which is
reasonably secure from prying eyes. If it happens
that the data is compromised, I have someone that can
pay for the damage in that the VAN is accountable.
Over the net, I don't, so therefore I must be
accountable. Again, I want to stress that XML nor EDI
have solved this problem. There are some heavy issues
involved here. Not the least of which is the federal
government here in the states. Until one can encrypt
with impunity and the web can be rendered truly
private, the reduction of costs for communications
provided by the net will not be without some real
compromises in privacy. Is this email moving via the
web truly private? No, but I don't really care if Joe
Sniffmeout in Cincinnati reads this. But, I'm not
putting my credit card number in it either.
Bottom line is that most people feel that the cost of
communicating between trading partners is the single
largest cost of EDI. It is true that the cost is a
variable and residual one that the controller or
responsible manager sees. But that cost will be
replaced by the costs to track and manage security
encryption standards and the like. By going to XML,
security costs will become a hidden one. No one will
be able to directly determine them. It will not
reduce the costs of doing e-commerce with others, it
will just hide them. I doubt seriously that XML will
reduce costs, it will more then likely raise them and
e-commerce will still remain as difficult to put in
place as it was before XML ever came into such popular
appeal.
Mark
PS. This is my opinion only. I've been involved in
EDI/e-commerce for about ten years as a coordinator,
analyst and implementation resource.
-----Original Message-----
From: Lee LoFrisco [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 24, 2000 6:09 AM
To: [EMAIL PROTECTED]
Subject: Re: XML for EDI book: Any comments?
I'm a bit confused about the benefits of XML. In a
traditional
EDI-intensive shop, where the supply-chain,
time-critical documents
are communicated electronically, and at a huge
savings, where would XML
improve this process? Granted, when communicating
between a web site and
desktop, XML has found a home. Entering a purchase
order via a web-based
entry screen, applying edits, and submitting the info
to an ERP system is a
practical, cost-effective method of order processing
for non-EDI orgs. But,
at some point along the way from entry to placing the
order, the XML file
needs to be translated to EDI (or some standard)
before updating or else an
org would have to maintain an endless list of unique
*maps* to accommodate
all the variations. Now, that sounds like EDI to me.
Without standards, which VP or Director is going to
stake his or her career
on recommending changing from traditional EDI to XML?
With millions of
dollars invested in effort and resources with EDI, and
with the documents
flowing, why change? XML builds larger files and has
yet to prove itself.
If it ain't broke, don't fix it!
Why all the hoopla about XML vs. EDI (unless of
course it's from the XML
software developers themselves)?
Lee LoFrisco
Sterling Commerce Service Partner Consultant
VoiceMail: 614.210.2706
Cell Phone: 410.963.6218
eFax: 810.277.5002
-----Original Message-----
From: Electronic Data Interchange Issues
[mailto:[EMAIL PROTECTED]]On Behalf Of Glass,
John K. III
Sent: Tuesday, October 24, 2000 7:16 AM
To: [EMAIL PROTECTED]
Subject: XML for EDI book: Any comments?
Hello group.
I was browsing through some books at amazon.com and
noticed a book that's
supposed to be coming out in November called:
Xml for Edi : Making E-Commerce a Reality
by Hussain Chinoy, Tyna Hull, Robi Sen
I was wondering if anyone has preordered this
book and if you have
heard any buzz about what it will contain. You guys
don't know of any other
books which dealt with this whole EDI/XML issue, do
you? Anyway, any info
that you have about this book would be appreciated.
Thanks.
=======================================================================To
signoff the EDI-L list,
mailto:[EMAIL PROTECTED]
To subscribe,
mailto:[EMAIL PROTECTED]
To contact the list owner:
mailto:[EMAIL PROTECTED]
Archives at
http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
=======================================================================To
signoff the EDI-L list,
mailto:[EMAIL PROTECTED]
To subscribe,
mailto:[EMAIL PROTECTED]
To contact the list owner:
mailto:[EMAIL PROTECTED]
Archives at
http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
--4200089-11519-972405935=:1504
Content-Type: TEXT/html; CHARSET=US-ASCII
Content-ID: 0
Content-Language: en-USA
<html><head></head><body>
<font size=2 >The
real truth about the XML vs. EDI is that XML is sexy. It's the newest
thing
to
come down the pipe in a long while. As far as performing "rip and read",
it
has merits and incentives for cost reduction that can be achieved very
quickly.</font><div>
<font size=2 ></font><div>
<font size=2 >Most
PC workstations today have XML enabled browsers or can be updated with them
very quickly at next to nothing in cost. That means that the XML data file
can
be displayed on the browser and made available to the direct user of the
information without much intervention between the gateway and the user. It
has
the potential of getting data to the person who needs it rapidly. This is
a
real advantage of XML and should be exploited if that is the
goal.</font><div>
<font size=2 ></font><div>
<font size=2 >Where
XML falls flat is in true business system integration between two separate
or
remote computer systems. The use of the new standards (I use this term
lightly
as they are changing faster then you can shake a stick) will require that
an
interface be either built for the XML centered transactions or that the
existing EDI interface programs be modified to handle the data provided.
The
second branch will be the method by which the implementation of XML
happens.
</font><div>
<font size=2 ></font><div>
<font size=2 >EDI
has always been envisioned as the enabling technology to allow information
from
one computer in a company to be transmitted to another company, translated,
and
loaded to that companies application. All EDI affiliated professionals
know
that this is the true crux of costs in accomplishing the "computer to
computer
integration of information". XML has NOT solved this problem, unless it's
cheaper to hire a clerk to sit, gather, and plug in what he/she sees on the
browser (I feel that this is a huge step backwards). </font><div>
<font size=2 ></font><div>
<font size=2 >Most
XML pundits believe that EDI cannot be communicated over the NET. Most
managers believe the same thing. THIS IS FALSE. EDI data will go just as
fast
as XML data. The problem which has not been solved by either standard is
that
the data (invoicing and ordering) must be secure between the two companies.
Not just the firewall, but the transmitted file of data moving across the
nodes
on the WEB. This means that a fast and reliable encryption must be used to
ensure that the data is not sniffed in the middle. XML's promise of
reduced
communications costs are given at the sacrifice of security.
Communications
via a VAN allow me to have an organization which is reasonably secure from
prying eyes. If it happens that the data is compromised, I have someone
that
can pay for the damage in that the VAN is accountable. Over the net, I
don't,
so therefore I must be accountable. Again, I want to stress that XML nor
EDI
have solved this problem. There are some heavy issues involved here. Not
the
least of which is the federal government here in the states. Until one can
encrypt with impunity and the web can be rendered truly private, the
reduction
of costs for communications provided by the net will not be without some
real
compromises in privacy. Is this email moving via the web truly private?
No,
but I don't really care if Joe Sniffmeout in Cincinnati reads this. But,
I'm
not putting my credit card number in it either.</font><div>
<font size=2 ></font><div>
<font size=2 >Bottom
line is that most people feel that the cost of communicating between
trading
partners is the single largest cost of EDI. It is true that the cost is a
variable and residual one that the controller or responsible manager sees.
But
that cost will be replaced by the costs to track and manage security
encryption
standards and the like. By going to XML, security costs will become a
hidden
one. No one will be able to directly determine them. It will not reduce
the
costs of doing e-commerce with others, it will just hide them. I doubt
seriously that XML will reduce costs, it will more then likely raise them
and
e-commerce will still remain as difficult to put in place as it was before
XML
ever came into such popular appeal.</font><div>
<font size=2 ></font><div>
<font size=2 >Mark</font><div>
<font size=2 ></font><div>
<font size=2 >PS.
This is my opinion only. I've been involved in EDI/e-commerce for about
ten
years as a coordinator, analyst and implementation resource.</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >-----Original
Message-----</font><div>
<font size=2 >From:
Lee LoFrisco [mailto:[EMAIL PROTECTED]]</font><div>
<font size=2 >Sent:
Tuesday, October 24, 2000 6:09 AM</font><div>
<font size=2 >To:
[EMAIL PROTECTED]</font><div>
<font size=2 >Subject:
Re: XML for EDI book: Any comments?</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >I'm
a bit confused about the benefits of XML. In a traditional</font><div>
<font size=2 >EDI-intensive
shop, where the supply-chain, time-critical documents</font><div>
<font size=2 >are
communicated electronically, and at a huge savings, where would
XML</font><div>
<font size=2 >improve
this process? Granted, when communicating between a web site
and</font><div>
<font size=2 >desktop,
XML has found a home. Entering a purchase order via a
web-based</font><div>
<font size=2 >entry
screen, applying edits, and submitting the info to an ERP system is
a</font><div>
<font size=2 >practical,
cost-effective method of order processing for non-EDI orgs.
But,</font><div>
<font size=2 >at
some point along the way from entry to placing the order, the XML
file</font><div>
<font size=2 >needs
to be translated to EDI (or some standard) before updating or else
an</font><div>
<font size=2 >org
would have to maintain an endless list of unique *maps* to
accommodate</font><div>
<font size=2 >all
the variations. Now, that sounds like EDI to me.</font><div>
<font size=2 ></font><div>
<font size=2 >Without
standards, which VP or Director is going to stake his or her
career</font><div>
<font size=2 >on
recommending changing from traditional EDI to XML? With millions
of</font><div>
<font size=2 >dollars
invested in effort and resources with EDI, and with the
documents</font><div>
<font size=2 >flowing,
why change? XML builds larger files and has yet to prove
itself.</font><div>
<font size=2 >If
it ain't broke, don't fix it!</font><div>
<font size=2 ></font><div>
<font size=2 >Why
all the hoopla about XML vs. EDI (unless of course it's from the
XML</font><div>
<font size=2 >software
developers themselves)?</font><div>
<font size=2 ></font><div>
<font size=2 >Lee
LoFrisco</font><div>
<font size=2 >Sterling
Commerce Service Partner Consultant</font><div>
<font size=2 >VoiceMail:
614.210.2706</font><div>
<font size=2 >Cell
Phone: 410.963.6218</font><div>
<font size=2 >eFax:
810.277.5002</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >-----Original
Message-----</font><div>
<font size=2 >From:
Electronic Data Interchange Issues</font><div>
<font size=2 >[mailto:[EMAIL PROTECTED]]On
Behalf Of Glass, John K. III</font><div>
<font size=2 >Sent:
Tuesday, October 24, 2000 7:16 AM</font><div>
<font size=2 >To:
[EMAIL PROTECTED]</font><div>
<font size=2 >Subject:
XML for EDI book: Any comments?</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >Hello
group.</font><div>
<font size=2 ></font><div>
<font size=2 >I
was browsing through some books at amazon.com and noticed a book
that's</font><div>
<font size=2 >supposed
to be coming out in November called:</font><div>
<font size=2 ></font><div>
<font size=2 >Xml
for Edi : Making E-Commerce a Reality</font><div>
<font size=2 >by
Hussain Chinoy, Tyna Hull, Robi Sen</font><div>
<font size=2 ></font><div>
<font size=2 >
I was wondering if anyone has preordered this book and if you
have</font><div>
<font size=2 >heard
any buzz about what it will contain. You guys don't know of any
other</font><div>
<font size=2 >books
which dealt with this whole EDI/XML issue, do you? Anyway, any
info</font><div>
<font size=2 >that
you have about this book would be appreciated.</font><div>
<font size=2 ></font><div>
<font size=2 >
Thanks.</font><div>
<font size=2 ></font><div>
<font size=2
>
=======================================================================</fo
nt><div>
<font size=2 >To
signoff the EDI-L list,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >To
subscribe,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >To
contact the list owner: mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >Archives
at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/</font><div>
<font size=2 ></font><div>
<font size=2 >_______________________________________________</font><div>
<font size=2 >Why
pay for something you could get for free?</font><div>
<font size=2 >NetZero
provides FREE Internet Access and Email</font><div>
<font size=2 >http://www.netzero.net/download/index.html</font><div>
<font size=2 ></font><div>
<font size=2
>
=======================================================================</fo
nt><div>
<font size=2 >To
signoff the EDI-L list,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >To
subscribe,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >To
contact the list owner: mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >Archives
at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/</font><div>
<font ></font></body></html>
--4200089-11519-972405935=:1504--
------------------------------
Date: Tue, 24 Oct 2000 12:27:25 -0500
From: Andy Sicignano <[EMAIL PROTECTED]>
Subject: Re: XML for EDI book: Any comments?
Mark,
I like a lot of what you said in your post, but I disagree on two points:
1) XML may indeed facilitate communication between trading partners. This
will require XSL transformation of messages. Although the W3C standards
are settling down, we need solid implementations for this to become a
reality.
2) It is already possible to send secure EDI transactions over the net;
we've been doing it for three years. It will probably become a lot cheaper
to do so in the near future, as vendors roll out products that conform to
IETF's EDIINT AS2 specification.
Andy
----------------------------------------------------------------------------
-----------------------------------------
Mark Kusiak <[EMAIL PROTECTED]>@LISTSERV.UCOP.EDU> on 10/24/2000 11:45:35
AM
Please respond to Mark Kusiak <[EMAIL PROTECTED]>
Sent by: Electronic Data Interchange Issues <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: XML for EDI book: Any comments?
The real truth about the XML vs. EDI is that XML is sexy. It's the newest
thing to come down the pipe in a long while. As far as performing "rip and
read", it has merits and incentives for cost reduction that can be achieved
very quickly.
Most PC workstations today have XML enabled browsers or can be updated with
them very quickly at next to nothing in cost. That means that the XML data
file can be displayed on the browser and made available to the direct user
of the information without much intervention between the gateway and the
user. It has the potential of getting data to the person who needs it
rapidly. This is a real advantage of XML and should be exploited if that
is the goal.
Where XML falls flat is in true business system integration between two
separate or remote computer systems. The use of the new standards (I use
this term lightly as they are changing faster then you can shake a stick)
will require that an interface be either built for the XML centered
transactions or that the existing EDI interface programs be modified to
handle the data provided. The second branch will be the method by which
the implementation of XML happens.
EDI has always been envisioned as the enabling technology to allow
information from one computer in a company to be transmitted to another
company, translated, and loaded to that companies application. All EDI
affiliated professionals know that this is the true crux of costs in
accomplishing the "computer to computer integration of information". XML
has NOT solved this problem, unless it's cheaper to hire a clerk to sit,
gather, and plug in what he/she sees on the browser (I feel that this is a
huge step backwards).
Most XML pundits believe that EDI cannot be communicated over the NET.
Most managers believe the same thing. THIS IS FALSE. EDI data will go
just as fast as XML data. The problem which has not been solved by either
standard is that the data (invoicing and ordering) must be secure between
the two companies. Not just the firewall, but the transmitted file of data
moving across the nodes on the WEB. This means that a fast and reliable
encryption must be used to ensure that the data is not sniffed in the
middle. XML's promise of reduced communications costs are given at the
sacrifice of security. Communications via a VAN allow me to have an
organization which is reasonably secure from prying eyes. If it happens
that the data is compromised, I have someone that can pay for the damage in
that the VAN is accountable. Over the net, I don't, so therefore I must be
accountable. Again, I want to stress that XML nor EDI have solved this
problem. There are some heavy issues involved here. Not the least of
which is the federal government here in the states. Until one can encrypt
with impunity and the web can be rendered truly private, the reduction of
costs for communications provided by the net will not be without some real
compromises in privacy. Is this email moving via the web truly private?
No, but I don't really care if Joe Sniffmeout in Cincinnati reads this.
But, I'm not putting my credit card number in it either.
Bottom line is that most people feel that the cost of communicating between
trading partners is the single largest cost of EDI. It is true that the
cost is a variable and residual one that the controller or responsible
manager sees. But that cost will be replaced by the costs to track and
manage security encryption standards and the like. By going to XML,
security costs will become a hidden one. No one will be able to directly
determine them. It will not reduce the costs of doing e-commerce with
others, it will just hide them. I doubt seriously that XML will reduce
costs, it will more then likely raise them and e-commerce will still remain
as difficult to put in place as it was before XML ever came into such
popular appeal.
Mark
PS. This is my opinion only. I've been involved in EDI/e-commerce for
about ten years as a coordinator, analyst and implementation resource.
-----Original Message-----
From: Lee LoFrisco [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 24, 2000 6:09 AM
To: [EMAIL PROTECTED]
Subject: Re: XML for EDI book: Any comments?
I'm a bit confused about the benefits of XML. In a traditional
EDI-intensive shop, where the supply-chain, time-critical documents
are communicated electronically, and at a huge savings, where would XML
improve this process? Granted, when communicating between a web site and
desktop, XML has found a home. Entering a purchase order via a web-based
entry screen, applying edits, and submitting the info to an ERP system is
practical, cost-effective method of order processing for non-EDI orgs.
But,
at some point along the way from entry to placing the order, the XML file
needs to be translated to EDI (or some standard) before updating or else an
org would have to maintain an endless list of unique *maps* to accommodate
all the variations. Now, that sounds like EDI to me.
Without standards, which VP or Director is going to stake his or her career
on recommending changing from traditional EDI to XML? With millions of
dollars invested in effort and resources with EDI, and with the documents
flowing, why change? XML builds larger files and has yet to prove itself.
If it ain't broke, don't fix it!
Why all the hoopla about XML vs. EDI (unless of course it's from the XML
software developers themselves)?
Lee LoFrisco
Sterling Commerce Service Partner Consultant
VoiceMail: 614.210.2706
Cell Phone: 410.963.6218
eFax: 810.277.5002
-----Original Message-----
From: Electronic Data Interchange Issues
[mailto:[EMAIL PROTECTED]]On Behalf Of Glass, John K. III
Sent: Tuesday, October 24, 2000 7:16 AM
To: [EMAIL PROTECTED]
Subject: XML for EDI book: Any comments?
Hello group.
I was browsing through some books at amazon.com and noticed a book that's
supposed to be coming out in November called:
Xml for Edi : Making E-Commerce a Reality
by Hussain Chinoy, Tyna Hull, Robi Sen
I was wondering if anyone has preordered this book and if you have
heard any buzz about what it will contain. You guys don't know of any
other
books which dealt with this whole EDI/XML issue, do you? Anyway, any info
that you have about this book would be appreciated.
Thanks.
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
------------------------------
Date: Tue, 24 Oct 2000 11:10:29 -0700
From: Brad <[EMAIL PROTECTED]>
Subject: Looking for some help.
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C03DE5.B5CA7B88
Content-Type: text/plain;
charset="iso-8859-1"
Well hope everyone is okay today. I myself am looking to find someone who
could help me with SpEDITran and MCBA Accounting system This is an old
system its running on Unix 2.1 and its the MCBA ver is all COBAL. I am not
a
COBAL programmer and the guy who is doing it now Is a nice chap but well
he's got other projects he wants to work on so this one is not getting much
attention.
Brad
------_=_NextPart_001_01C03DE5.B5CA7B88
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Looking for some help.</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2 FACE=3D"Arial">Well hope everyone is okay today. I =
myself am looking to find someone who could help me with SpEDITran and =
MCBA Accounting system This is an old system its running on Unix 2.1 =
and its the MCBA ver is all COBAL. I am not a COBAL programmer and the =
guy who is doing it now Is a nice chap but well he's got other projects =
he wants to work on so this one is not getting much =
attention.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Brad</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C03DE5.B5CA7B88--
------------------------------
Date: Tue, 24 Oct 2000 11:37:07 -0700
From: Dave Taylor <[EMAIL PROTECTED]>
Subject: Re: XML for EDI book: Any comments?
Andy,
I just talked with Cyclone about their EDIINT-compliant product and they
quoted me an annual license fee of $18,000 on NT or W2K, or a 1-time charge
of $52,000. It goes up for various flavors of Unix and even higher for
OS/390.
Do you know of any less expensive EDIINT-compliant communications
solutions?
This is pretty stiff for most small/mediuim size companies trying to
utilize
integrated EDI.
Dave
----- Original Message -----
From: "Andy Sicignano" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 24, 2000 10:27 AM
Subject: Re: XML for EDI book: Any comments?
> Mark,
> I like a lot of what you said in your post, but I disagree on two points:
>
> 1) XML may indeed facilitate communication between trading partners.
This
> will require XSL transformation of messages. Although the W3C standards
> are settling down, we need solid implementations for this to become a
> reality.
>
> 2) It is already possible to send secure EDI transactions over the net;
> we've been doing it for three years. It will probably become a lot
cheaper
> to do so in the near future, as vendors roll out products that conform to
> IETF's EDIINT AS2 specification.
>
> Andy
>
--------------------------------------------------------------------------
-------------------------------------------
>
>
>
>
> Mark Kusiak <[EMAIL PROTECTED]>@LISTSERV.UCOP.EDU> on 10/24/2000
11:45:35
> AM
>
> Please respond to Mark Kusiak <[EMAIL PROTECTED]>
>
> Sent by: Electronic Data Interchange Issues <[EMAIL PROTECTED]>
>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Re: XML for EDI book: Any comments?
>
>
> The real truth about the XML vs. EDI is that XML is sexy. It's the
newest
> thing to come down the pipe in a long while. As far as performing "rip
and
> read", it has merits and incentives for cost reduction that can be
achieved
> very quickly.
>
> Most PC workstations today have XML enabled browsers or can be updated
with
> them very quickly at next to nothing in cost. That means that the XML
data
> file can be displayed on the browser and made available to the direct
user
> of the information without much intervention between the gateway and the
> user. It has the potential of getting data to the person who needs it
> rapidly. This is a real advantage of XML and should be exploited if that
> is the goal.
>
> Where XML falls flat is in true business system integration between two
> separate or remote computer systems. The use of the new standards (I use
> this term lightly as they are changing faster then you can shake a stick)
> will require that an interface be either built for the XML centered
> transactions or that the existing EDI interface programs be modified to
> handle the data provided. The second branch will be the method by which
> the implementation of XML happens.
>
> EDI has always been envisioned as the enabling technology to allow
> information from one computer in a company to be transmitted to another
> company, translated, and loaded to that companies application. All EDI
> affiliated professionals know that this is the true crux of costs in
> accomplishing the "computer to computer integration of information". XML
> has NOT solved this problem, unless it's cheaper to hire a clerk to sit,
> gather, and plug in what he/she sees on the browser (I feel that this is
a
> huge step backwards).
>
> Most XML pundits believe that EDI cannot be communicated over the NET.
> Most managers believe the same thing. THIS IS FALSE. EDI data will go
> just as fast as XML data. The problem which has not been solved by
either
> standard is that the data (invoicing and ordering) must be secure between
> the two companies. Not just the firewall, but the transmitted file of
data
> moving across the nodes on the WEB. This means that a fast and reliable
> encryption must be used to ensure that the data is not sniffed in the
> middle. XML's promise of reduced communications costs are given at the
> sacrifice of security. Communications via a VAN allow me to have an
> organization which is reasonably secure from prying eyes. If it happens
> that the data is compromised, I have someone that can pay for the damage
in
> that the VAN is accountable. Over the net, I don't, so therefore I must
be
> accountable. Again, I want to stress that XML nor EDI have solved this
> problem. There are some heavy issues involved here. Not the least of
> which is the federal government here in the states. Until one can
encrypt
> with impunity and the web can be rendered truly private, the reduction of
> costs for communications provided by the net will not be without some
real
> compromises in privacy. Is this email moving via the web truly private?
> No, but I don't really care if Joe Sniffmeout in Cincinnati reads this.
> But, I'm not putting my credit card number in it either.
>
> Bottom line is that most people feel that the cost of communicating
between
> trading partners is the single largest cost of EDI. It is true that the
> cost is a variable and residual one that the controller or responsible
> manager sees. But that cost will be replaced by the costs to track and
> manage security encryption standards and the like. By going to XML,
> security costs will become a hidden one. No one will be able to directly
> determine them. It will not reduce the costs of doing e-commerce with
> others, it will just hide them. I doubt seriously that XML will reduce
> costs, it will more then likely raise them and e-commerce will still
remain
> as difficult to put in place as it was before XML ever came into such
> popular appeal.
>
> Mark
>
> PS. This is my opinion only. I've been involved in EDI/e-commerce for
> about ten years as a coordinator, analyst and implementation resource.
>
>
>
> -----Original Message-----
> From: Lee LoFrisco [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 24, 2000 6:09 AM
> To: [EMAIL PROTECTED]
> Subject: Re: XML for EDI book: Any comments?
>
>
> I'm a bit confused about the benefits of XML. In a traditional
> EDI-intensive shop, where the supply-chain, time-critical documents
> are communicated electronically, and at a huge savings, where would XML
> improve this process? Granted, when communicating between a web site and
> desktop, XML has found a home. Entering a purchase order via a web-based
> entry screen, applying edits, and submitting the info to an ERP system is
> practical, cost-effective method of order processing for non-EDI orgs.
> But,
> at some point along the way from entry to placing the order, the XML file
> needs to be translated to EDI (or some standard) before updating or else
an
> org would have to maintain an endless list of unique *maps* to
accommodate
> all the variations. Now, that sounds like EDI to me.
>
> Without standards, which VP or Director is going to stake his or her
career
> on recommending changing from traditional EDI to XML? With millions of
> dollars invested in effort and resources with EDI, and with the documents
> flowing, why change? XML builds larger files and has yet to prove
itself.
> If it ain't broke, don't fix it!
>
> Why all the hoopla about XML vs. EDI (unless of course it's from the XML
> software developers themselves)?
>
> Lee LoFrisco
> Sterling Commerce Service Partner Consultant
> VoiceMail: 614.210.2706
> Cell Phone: 410.963.6218
> eFax: 810.277.5002
>
>
> -----Original Message-----
> From: Electronic Data Interchange Issues
> [mailto:[EMAIL PROTECTED]]On Behalf Of Glass, John K. III
> Sent: Tuesday, October 24, 2000 7:16 AM
> To: [EMAIL PROTECTED]
> Subject: XML for EDI book: Any comments?
>
>
> Hello group.
>
> I was browsing through some books at amazon.com and noticed a book that's
> supposed to be coming out in November called:
>
> Xml for Edi : Making E-Commerce a Reality
> by Hussain Chinoy, Tyna Hull, Robi Sen
>
> I was wondering if anyone has preordered this book and if you have
> heard any buzz about what it will contain. You guys don't know of any
> other
> books which dealt with this whole EDI/XML issue, do you? Anyway, any
info
> that you have about this book would be appreciated.
>
> Thanks.
>
> =======================================================================
> To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
> To subscribe, mailto:[EMAIL PROTECTED]
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
> _______________________________________________
> Why pay for something you could get for free?
> NetZero provides FREE Internet Access and Email
> http://www.netzero.net/download/index.html
>
> =======================================================================
> To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
> To subscribe, mailto:[EMAIL PROTECTED]
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
> =======================================================================
> To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
> To subscribe, mailto:[EMAIL PROTECTED]
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
------------------------------
Date: Tue, 24 Oct 2000 13:37:37 -0500
From: A Hilton <[EMAIL PROTECTED]>
Subject: Re: XML for EDI book: Any comments?
For me, as a developer, the key to the XML formatting structure is
flexibility. The "Process of EDI" doesn't change with differing format
(X12/EDIFACT/XML-based). I would answer your original question by saying
that by having an XML-based EDI format will allow one to reach new
partners;
interact with new or existing partners in different and flexible ways; and
utilize new (and sometimes even effective <g>) automated processes to reach
your suppliers/customers. Does that sound enough like the verbage in the
trade mags?
Seriously though, I find the XML formatting structure of those clients I
help 'do EDI' allows them to gain the benefits of the "Process of EDI" and
still have flexibility in how that data gets moved around. It really is, in
my opinion, just a matter of moving bits around. The REAL work is in that
"Process of EDI" (as I like to call it... as you can tell) and it has very
little to do with the formatting structure.
>
> I'm a bit confused about the benefits of XML. In a traditional
> EDI-intensive shop, where the supply-chain, time-critical documents
......
>
> Lee LoFrisco
> Sterling Commerce Service Partner Consultant
> VoiceMail: 614.210.2706
> Cell Phone: 410.963.6218
> eFax: 810.277.5002
Just a view from the trenches...
- A Hilton
------------------------------
Date: Tue, 24 Oct 2000 13:57:55 -0500
From: Andy Sicignano <[EMAIL PROTECTED]>
Subject: Re: XML for EDI book: Any comments?
Dave,
No, sorry I don't: ours is home-grown. I do know of one or two shops that
were working on an AS2 product, but I don't know if they are GA. I do
expect prices to come down once the competition heats up. If you like, I
can forward this note...
Andy
----------------------------------------------------------------------------
------------------------------------------------
Dave Taylor <[EMAIL PROTECTED]>@LISTSERV.UCOP.EDU> on 10/24/2000
01:37:07 PM
Please respond to Dave Taylor <[EMAIL PROTECTED]>
Sent by: Electronic Data Interchange Issues <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: XML for EDI book: Any comments?
Andy,
I just talked with Cyclone about their EDIINT-compliant product and they
quoted me an annual license fee of $18,000 on NT or W2K, or a 1-time charge
of $52,000. It goes up for various flavors of Unix and even higher for
OS/390.
Do you know of any less expensive EDIINT-compliant communications
solutions?
This is pretty stiff for most small/mediuim size companies trying to
utilize
integrated EDI.
Dave
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
------------------------------
Date: Tue, 24 Oct 2000 14:38:28 -0700
From: Mark Kusiak <[EMAIL PROTECTED]>
Subject: Re: XML for EDI book: Any comments?
--10114533-11930-972423508=:1012
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Language: en-USA
Dave and Andy,
Where did the "cost savings" for the SME go in light
of this information?
It seems that the cost is being shifted around, not
reduced. 18K a year
is fairly close to what I pay the VAN to transport and
house my data now.
Again, where is the cost savings. It seems that the
fence to e-commerce capability
is still one of money. An SME will have to still lay
out an ante if they are going to
get into the game.
I find given the model presented below, that at best
the costs are about the same. I know
that the model below will not fit all situations and
god forbid that an 800 Lb gorilla gets
mixed into the projection. The model assumes that the
implementer is going to do everything
to ensure that they are safe and that the implementer
is well educated in e-commerce requirements.
I think that if you plug your associated number into
the model below you will have a fairly
accurate number of what it will cost you to START UP.
This cost analysis runs through year 5 of
an operation which will place you in an area of
obsolescence.
I consider that the information passed under the model
is application to application integration
of the data. Anything less will be required to add in
the additional labor needed to gather
and enter the data into the system. Labor costs are
calculated on a full time programmer being
employed and may be a little low. I'm calculating
based on a $50.00 per hour wage and fringe
cost.
To do "e-commerce", one must have as a minimum these
components to play. Pick one of either
component number 3 or 4 to arrive at a bottom line
year one start up. You may be required
to use both 3 and 4 dependent on the capability of the
trading partner. If your trading partners
are primarily customers, you will definitely be doing
both.
Rule one is that the customer is always right.
Rule two, is in all other situations refer back to
rule number 1.
1 An "interface" to their backend application that
allows for the import/extract of data
for each system/transaction set EDI or XML. Cost
to Build at $50.00 per hour fringe and
benefits for a programmer and figuring for on
average of about six man weeks at 40 hours a
week. There are usually no off-the-shelf packages
to accomplish this for you, and one
size does not fit all.
12,000.00 per system
2 An EDI/XML translator package. Purchasing a
vendors product is assumed to be the
cheapest way to go as it is unknown how much time
and programming resources are needed
to build one. I'll give you an SME quote for a PC
based front end system. This is
the way most start into the game.
7,000.00 per license*
This cost is a recent quote from a vendor which
I won't name. This is for a
larger fortune 500 corporation and I'm sure
that the amount reflects that.
32,000.00 per license*
* It should be noted that these translator
packages come in all sizes and flavors
and can very in price dependent on what your
budget is. The common PC based
package will cost around $5,000.00 to $7,000.00.
Cost increases as capability
and bells and whistles go up.
Each of the packages will have a service plan for
support based on the needs of the company.
This varies by the vendor of the package and
depends on the support plan needed. Very few
vendors will provide 7/24 support operations, but
if they do, you will pay. Based on 5/8
support, you can expect this amount. It does
differ between vendors.
2,000.00 per license.
3 To use the web, an encryption package to secure the
data for transport over unsecured
web nodes as quoted below. It is assumed that the
one time fee is best here. It is
assumed that an eventual break even point would be
reached. This is optional but I
would say to you don't put your credit card number
in your data if your not using it.
Also, don't expect privacy of your data.
52,000.00 per license
4 Use of a Value Added Network (VAN) Based on
non-negotiated byte count amounts and the
users knowledge level.
Start up fee one time beginning dependent on
VAN 500.00 to start
Byte push charges, they differ per van
9,600.00 based on volume
Subscription Fee
1,200.00 per year
Using the above quoted costs, here is the breakdown
for the cost of getting into the game either
way for a well heeled SME to fully automate A/P, A/R,
Purchasing, and Order Processing. We are
assuming that the trading partners for this SME are
customers and that the SME is going to end
up complying with all the differences of the trading
partner. This may or may not be the case.
Traditional EDI Start Up and operation for 5
Years assuming no obsolescence of interface or
translation packages.
1 Interface to Account's Payable
12,000.00 These first 4 are labor costs
2 Interface to Account's Receivable
12,000.00
3 Interface to Purchasing
12,000.00
4 Interface to Order Processing
12,000.00
5 Purchase of the Translator
7,000.00
6 Purchase of a support package 5/8
2,000.00
7 Subscription to One VAN(1)
1,200.00
8 Byte Count for data transmission via a VAN
9,600.00
----------
TOTAL
$67,800.00 First Year Start Up
Once you are up figure about 1/2 of the
development cost to maintain
the interfaces based on new trading partners
and requirements in each
subsequent year.
1 Interface to Account's Payable
6,000.00 These first 4 are labor costs
2 Interface to Account's Receivable
6,000.00
3 Interface to Purchasing
6,000.00
4 Interface to Order Processing
6,000.00
6 Purchase of a support package 5/8
2,000.00
7 Subscription to One VAN(1)
1,200.00
8 Byte Count for data transmission via a VAN
9,600.00
---------
$36,800.00 Second through Fifth Year Operations.
Total 5 year cost of doing Traditional EDI.
$215,000.00
(1) You may be looking at additional VAN's dependent
on the needs of the trading partner (customer).
Traditional EDI/XML Start up and operations for 5
year period also assuming no obsolescence of the
translator, encryption package and assuming that
you are only using web communications with trading
partners. All Trading partners are customers and
SME will comply across the spectrum with all
requirements
placed on Them,
1 Interface to Account's Payable
12,000.00 These first 4 are labor costs
2 Interface to Account's Receivable
12,000.00
3 Interface to Purchasing
12,000.00
4 Interface to Order Processing
12,000.00
5 Purchase of the Translator
7,000.00
6 Purchase of a support package 5/8
2,000.00
7 Purchase of an Encryption Package (one time)
52,000.00
8 Purchase of Support 5/40
5,200.00 10% of list is usual.
----------
TOTAL Year One Start Up Costs
114,200.00 First Year Start Up.
Again figure about 1/2 of the development costs to
maintain interface through years 2 - 5.
1 Interface to Account's Payable
6,000.00 These first 4 are labor costs
2 Interface to Account's Receivable
6,000.00
3 Interface to Purchasing
6,000.00
4 Interface to Order Processing
6,000.00
5 Purchase of a support package 5/8 Translator
2,000.00
6 Purchase of Support 5/40
5,200.00 10% of list is usual.
----------
TOTAL Cost years 2 through 5
36,200.00 Year two through five costs.
Total 5 year cost XML/EDI via WEB.
$259,000.00
Combined traditional and web based EDI/XML system
start up and operations also assuming no obsolescence
of the translator, encryption or other components.
This model assumes the use of both a VAN and
WEB based communications. All trading partners are
customers and the SME will comply with all requirements
placed on them.
1 Interface to Account's Payable
12,000.00 These first 4 are labor costs
2 Interface to Account's Receivable
12,000.00
3 Interface to Purchasing
12,000.00
4 Interface to Order Processing
12,000.00
5 Purchase of the Translator
7,000.00
6 Purchase of a support package 5/8
2,000.00
7 Purchase of an Encryption Package (one time)
52,000.00
8 Purchase of Support 5/40
5,200.00 10% of list is usual.
9 Subscription to One VAN(1)
1,200.00
10 Byte Count for data transmission via a VAN
9,600.00 Cost varies dependent on volumes of data.
---------
TOTAL Costs year 1 start up.
$125,000.00 First Year Costs of Start up.
Again figure about 1/2 of the development costs
to maintain interface through years 2 - 5.
1 Interface to Account's Payable
6,000.00 These first 4 are labor costs
2 Interface to Account's Receivable
6,000.00
3 Interface to Purchasing
6,000.00
4 Interface to Order Processing
6,000.00
6 Purchase of a support package 5/8
2,000.00
8 Purchase of Support 5/40
5,200.00 10% of list is usual.
9 Subscription to One VAN(1)
1,200.00
10 Byte Count for data transmission via a VAN
9,600.00 Cost varies dependent on volumes of data.
---------
TOTAL COST, years 2 - 5
$ 42,000.00 Cost of operations years 2 - 5
TOTAL COST 5 Year operations WEB/Traditional Combined
$293,000.00
Mark
-----Original Message-----
From: Dave Taylor [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 24, 2000 11:37 AM
To: [EMAIL PROTECTED]
Subject: Re: XML for EDI book: Any comments?
Andy,
I just talked with Cyclone about their
EDIINT-compliant product and they
quoted me an annual license fee of $18,000 on NT or
W2K, or a 1-time charge
of $52,000. It goes up for various flavors of Unix
and even higher for
OS/390.
Do you know of any less expensive EDIINT-compliant
communications solutions?
This is pretty stiff for most small/mediuim size
companies trying to utilize
integrated EDI.
Dave
----- Original Message -----
From: "Andy Sicignano" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 24, 2000 10:27 AM
Subject: Re: XML for EDI book: Any comments?
> Mark,
> I like a lot of what you said in your post, but I
disagree on two points:
>
> 1) XML may indeed facilitate communication between
trading partners. This
> will require XSL transformation of messages.
Although the W3C standards
> are settling down, we need solid implementations
for this to become a
> reality.
>
> 2) It is already possible to send secure EDI
transactions over the net;
> we've been doing it for three years. It will
probably become a lot
cheaper
> to do so in the near future, as vendors roll out
products that conform to
> IETF's EDIINT AS2 specification.
>
> Andy
>
----------------------------------------------------------------------------
-----------------------------------------
>
>
>
>
> Mark Kusiak <[EMAIL PROTECTED]>@LISTSERV.UCOP.EDU>
on 10/24/2000
11:45:35
> AM
>
> Please respond to Mark Kusiak <[EMAIL PROTECTED]>
>
> Sent by: Electronic Data Interchange Issues
<[EMAIL PROTECTED]>
>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Re: XML for EDI book: Any comments?
>
>
> The real truth about the XML vs. EDI is that XML is
sexy. It's the newest
> thing to come down the pipe in a long while. As far
as performing "rip
and
> read", it has merits and incentives for cost
reduction that can be
achieved
> very quickly.
>
> Most PC workstations today have XML enabled browsers
or can be updated
with
> them very quickly at next to nothing in cost. That
means that the XML
data
> file can be displayed on the browser and made
available to the direct user
> of the information without much intervention between
the gateway and the
> user. It has the potential of getting data to the
person who needs it
> rapidly. This is a real advantage of XML and should
be exploited if that
> is the goal.
>
> Where XML falls flat is in true business system
integration between two
> separate or remote computer systems. The use of the
new standards (I use
> this term lightly as they are changing faster then
you can shake a stick)
> will require that an interface be either built for
the XML centered
> transactions or that the existing EDI interface
programs be modified to
> handle the data provided. The second branch will be
the method by which
> the implementation of XML happens.
>
> EDI has always been envisioned as the enabling
technology to allow
> information from one computer in a company to be
transmitted to another
> company, translated, and loaded to that companies
application. All EDI
> affiliated professionals know that this is the true
crux of costs in
> accomplishing the "computer to computer integration
of information". XML
> has NOT solved this problem, unless it's cheaper to
hire a clerk to sit,
> gather, and plug in what he/she sees on the browser
(I feel that this is a
> huge step backwards).
>
> Most XML pundits believe that EDI cannot be
communicated over the NET.
> Most managers believe the same thing. THIS IS
FALSE. EDI data will go
> just as fast as XML data. The problem which has not
been solved by either
> standard is that the data (invoicing and ordering)
must be secure between
> the two companies. Not just the firewall, but the
transmitted file of data
> moving across the nodes on the WEB. This means that
a fast and reliable
> encryption must be used to ensure that the data is
not sniffed in the
> middle. XML's promise of reduced communications
costs are given at the
> sacrifice of security. Communications via a VAN
allow me to have an
> organization which is reasonably secure from prying
eyes. If it happens
> that the data is compromised, I have someone that
can pay for the damage
in
> that the VAN is accountable. Over the net, I don't,
so therefore I must
be
> accountable. Again, I want to stress that XML nor
EDI have solved this
> problem. There are some heavy issues involved here.
Not the least of
> which is the federal government here in the states.
Until one can encrypt
> with impunity and the web can be rendered truly
private, the reduction of
> costs for communications provided by the net will
not be without some real
> compromises in privacy. Is this email moving via
the web truly private?
> No, but I don't really care if Joe Sniffmeout in
Cincinnati reads this.
> But, I'm not putting my credit card number in it
either.
>
> Bottom line is that most people feel that the cost
of communicating
between
> trading partners is the single largest cost of EDI.
It is true that the
> cost is a variable and residual one that the
controller or responsible
> manager sees. But that cost will be replaced by the
costs to track and
> manage security encryption standards and the like.
By going to XML,
> security costs will become a hidden one. No one
will be able to directly
> determine them. It will not reduce the costs of
doing e-commerce with
> others, it will just hide them. I doubt seriously
that XML will reduce
> costs, it will more then likely raise them and
e-commerce will still
remain
> as difficult to put in place as it was before XML
ever came into such
> popular appeal.
>
> Mark
>
> PS. This is my opinion only. I've been involved in
EDI/e-commerce for
> about ten years as a coordinator, analyst and
implementation resource.
>
>
>
> -----Original Message-----
> From: Lee LoFrisco [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 24, 2000 6:09 AM
> To: [EMAIL PROTECTED]
> Subject: Re: XML for EDI book: Any comments?
>
>
> I'm a bit confused about the benefits of XML. In a
traditional
> EDI-intensive shop, where the supply-chain,
time-critical documents
> are communicated electronically, and at a huge
savings, where would XML
> improve this process? Granted, when communicating
between a web site and
> desktop, XML has found a home. Entering a purchase
order via a web-based
> entry screen, applying edits, and submitting the
info to an ERP system is
> practical, cost-effective method of order processing
for non-EDI orgs.
> But,
> at some point along the way from entry to placing
the order, the XML file
> needs to be translated to EDI (or some standard)
before updating or else
an
> org would have to maintain an endless list of unique
*maps* to accommodate
> all the variations. Now, that sounds like EDI to me.
>
> Without standards, which VP or Director is going to
stake his or her
career
> on recommending changing from traditional EDI to
XML? With millions of
> dollars invested in effort and resources with EDI,
and with the documents
> flowing, why change? XML builds larger files and
has yet to prove itself.
> If it ain't broke, don't fix it!
>
> Why all the hoopla about XML vs. EDI (unless of
course it's from the XML
> software developers themselves)?
>
> Lee LoFrisco
> Sterling Commerce Service Partner Consultant
> VoiceMail: 614.210.2706
> Cell Phone: 410.963.6218
> eFax: 810.277.5002
>
>
> -----Original Message-----
> From: Electronic Data Interchange Issues
> [mailto:[EMAIL PROTECTED]]On Behalf Of Glass,
John K. III
> Sent: Tuesday, October 24, 2000 7:16 AM
> To: [EMAIL PROTECTED]
> Subject: XML for EDI book: Any comments?
>
>
> Hello group.
>
> I was browsing through some books at amazon.com and
noticed a book that's
> supposed to be coming out in November called:
>
> Xml for Edi : Making E-Commerce a Reality
> by Hussain Chinoy, Tyna Hull, Robi Sen
>
> I was wondering if anyone has preordered this book
and if you have
> heard any buzz about what it will contain. You guys
don't know of any
> other
> books which dealt with this whole EDI/XML issue, do
you? Anyway, any info
> that you have about this book would be appreciated.
>
> Thanks.
>
>
=======================================================================> To
signoff the EDI-L list,
mailto:[EMAIL PROTECTED]
> To subscribe,
mailto:[EMAIL PROTECTED]
> To contact the list owner:
mailto:[EMAIL PROTECTED]
> Archives at
http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
> _______________________________________________
> Why pay for something you could get for free?
> NetZero provides FREE Internet Access and Email
> http://www.netzero.net/download/index.html
>
>
=======================================================================> To
signoff the EDI-L list,
mailto:[EMAIL PROTECTED]
> To subscribe,
mailto:[EMAIL PROTECTED]
> To contact the list owner:
mailto:[EMAIL PROTECTED]
> Archives at
http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
>
=======================================================================> To
signoff the EDI-L list,
mailto:[EMAIL PROTECTED]
> To subscribe,
mailto:[EMAIL PROTECTED]
> To contact the list owner:
mailto:[EMAIL PROTECTED]
> Archives at
http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================To
signoff the EDI-L list,
mailto:[EMAIL PROTECTED]
To subscribe,
mailto:[EMAIL PROTECTED]
To contact the list owner:
mailto:[EMAIL PROTECTED]
Archives at
http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
--10114533-11930-972423508=:1012
Content-Type: TEXT/html; CHARSET=US-ASCII
Content-ID: 0
Content-Language: en-USA
<html><head></head><body>
<font size=2 >Dave
and Andy,</font><div>
<font size=2 ></font><div>
<font size=2 >Where
did the "cost savings" for the SME go in light of this
information?</font><div>
<font size=2 >It
seems that the cost is being shifted around, not reduced. 18K a year
</font><div>
<font size=2 >is
fairly close to what I pay the VAN to transport and house my data
now.</font><div>
<font size=2 ></font><div>
<font size=2 >Again,
where is the cost savings. It seems that the fence to e-commerce
capability
</font><div>
<font size=2 >is
still one of money. An SME will have to still lay out an ante if they are
going to </font><div>
<font size=2 >get
into the game. </font><div>
<font size=2 ></font><div>
<font size=2 >I
find given the model presented below, that at best the costs are about the
same. I know </font><div>
<font size=2 >that
the model below will not fit all situations and god forbid that an 800 Lb
gorilla gets </font><div>
<font size=2 >mixed
into the projection. The model assumes that the implementer is going to do
everything</font><div>
<font size=2 >to
ensure that they are safe and that the implementer is well educated in
e-commerce requirements.</font><div>
<font size=2 >I
think that if you plug your associated number into the model below you will
have a fairly </font><div>
<font size=2 >accurate
number of what it will cost you to START UP. This cost analysis runs
through
year 5 of </font><div>
<font size=2 >an
operation which will place you in an area of obsolescence. </font><div>
<font size=2 ></font><div>
<font size=2 >I
consider that the information passed under the model is application to
application integration</font><div>
<font size=2 >of
the data. Anything less will be required to add in the additional labor
needed
to gather </font><div>
<font size=2 >and
enter the data into the system. Labor costs are calculated on a full time
programmer being </font><div>
<font size=2 >employed
and may be a little low. I'm calculating based on a $50.00 per hour wage
and
fringe </font><div>
<font size=2 >cost.</font><div>
<font size=2 ></font><div>
<font size=2 >To
do "e-commerce", one must have as a minimum these components to play. Pick
one
of either </font><div>
<font size=2 >component
number 3 or 4 to arrive at a bottom line year one start up. You may be
required </font><div>
<font size=2 >to
use both 3 and 4 dependent on the capability of the trading partner. If
your
trading partners </font><div>
<font size=2 >are
primarily customers, you will definitely be doing both. </font><div>
<font size=2 ></font><div>
<font size=2 >Rule
one is that the customer is always right.</font><div>
<font size=2 >Rule
two, is in all other situations refer back to rule number 1.</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >1
An "interface" to their backend application that allows for the
import/extract
of data</font><div>
<font size=2 >
for each system/transaction set EDI or XML. Cost to Build at $50.00 per
hour
fringe and </font><div>
<font size=2 >
benefits for a programmer and figuring for on average of about six man
weeks
at 40 hours a </font><div>
<font size=2 >
week. There are usually no off-the-shelf packages to accomplish this for
you, and one </font><div>
<font size=2 >
size does not fit all. </font><div>
<font size=2 ></font><div>
<font size=2 >
12,000.00
per system</font><div>
<font size=2 ></font><div>
<font size=2 >2
An EDI/XML translator package. Purchasing a vendors product is assumed to
be
the </font><div>
<font size=2 >
cheapest way to go as it is unknown how much time and programming
resources
are needed</font><div>
<font size=2 >
to build one. I'll give you an SME quote for a PC based front end
system.
This is </font><div>
<font size=2 >
the way most start into the game.</font><div>
<font size=2 ></font><div>
<font size=2 >
7,000.00
per license*</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >
This cost is a recent quote from a vendor which I won't name. This
is
for a </font><div>
<font size=2 >
larger fortune 500 corporation and I'm sure that the amount reflects
that.</font><div>
<font size=2 >
</font><div>
<font size=2 ></font><div>
<font size=2 >
32,000.00
per license*</font><div>
<font size=2 ></font><div>
<font size=2 >
* It should be noted that these translator packages come in all sizes
and
flavors</font><div>
<font size=2 >
and can very in price dependent on what your budget is. The common PC
based </font><div>
<font size=2 >
package will cost around $5,000.00 to $7,000.00. Cost increases as
capability </font><div>
<font size=2 >
and bells and whistles go up. </font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >
Each of the packages will have a service plan for support based on the
needs
of the company.</font><div>
<font size=2 >
This varies by the vendor of the package and depends on the support plan
needed. Very few</font><div>
<font size=2 >
vendors will provide 7/24 support operations, but if they do, you will
pay.
Based on 5/8 </font><div>
<font size=2 >
support, you can expect this amount. It does differ between
vendors.</font><div>
<font size=2 ></font><div>
<font size=2 >
2,000.00
per license.</font><div>
<font size=2 ></font><div>
<font size=2 >3
To use the web, an encryption package to secure the data for transport
over
unsecured </font><div>
<font size=2 >
web nodes as quoted below. It is assumed that the one time fee is best
here.
It is </font><div>
<font size=2 >
assumed that an eventual break even point would be reached. This is
optional
but I </font><div>
<font size=2 >
would say to you don't put your credit card number in your data if your
not
using it.</font><div>
<font size=2 >
Also, don't expect privacy of your data.</font><div>
<font size=2 ></font><div>
<font size=2 >
52,000.00
per license </font><div>
<font size=2 ></font><div>
<font size=2 >4
Use of a Value Added Network (VAN) Based on non-negotiated byte count
amounts
and the </font><div>
<font size=2 >
users knowledge level.</font><div>
<font size=2 ></font><div>
<font size=2 >
Start up fee one time beginning dependent on VAN
500.00
to
start</font><div>
<font size=2 >
Byte push charges, they differ per van
9,600.00
based on volume</font><div>
<font size=2 >
Subscription Fee
1,200.00 per year</font><div>
<font size=2 ></font><div>
<font size=2 >Using
the above quoted costs, here is the breakdown for the cost of getting into
the
game either</font><div>
<font size=2 >way
for a well heeled SME to fully automate A/P, A/R, Purchasing, and Order
Processing. We are </font><div>
<font size=2 >assuming
that the trading partners for this SME are customers and that the SME is
going
to end </font><div>
<font size=2 >up
complying with all the differences of the trading partner. This may or may
not
be the case.</font><div>
<font size=2 ></font><div>
<font size=2 >
Traditional EDI Start Up and operation for 5 Years assuming no
obsolescence of interface or </font><div>
<font size=2 >
translation packages.</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >1
Interface to Account's Payable 12,000.00 These
first
4
are labor costs</font><div>
<font size=2 >2
Interface to Account's Receivable 12,000.00</font><div>
<font size=2 >3
Interface to Purchasing 12,000.00</font><div>
<font size=2 >4
Interface to Order Processing 12,000.00</font><div>
<font size=2 >5
Purchase of the Translator 7,000.00</font><div>
<font size=2 >6
Purchase of a support package 5/8 2,000.00</font><div>
<font size=2 >7
Subscription to One VAN(1) 1,200.00</font><div>
<font size=2 >8
Byte Count for data transmission via a VAN 9,600.00</font><div>
<font size=2 >
----------</font><div>
<font size=2 >
TOTAL $67,800.00 First
Year
Start Up</font><div>
<font size=2 ></font><div>
<font size=2 >
Once you are up figure about 1/2 of the development cost to
maintain</font><div>
<font size=2 >
the interfaces based on new trading partners and requirements in
each</font><div>
<font size=2 >
subsequent year.</font><div>
<font size=2 ></font><div>
<font size=2 >1
Interface to Account's Payable 6,000.00 These
first
4
are labor costs</font><div>
<font size=2 >2
Interface to Account's Receivable 6,000.00</font><div>
<font size=2 >3
Interface to Purchasing 6,000.00</font><div>
<font size=2 >4
Interface to Order Processing 6,000.00</font><div>
<font size=2 >6
Purchase of a support package 5/8 2,000.00</font><div>
<font size=2 >7
Subscription to One VAN(1) 1,200.00</font><div>
<font size=2 >8
Byte Count for data transmission via a VAN 9,600.00</font><div>
<font size=2 >
---------</font><div>
<font size=2 >
$36,800.00 Second
through
Fifth Year Operations.</font><div>
<font size=2 ></font><div>
<font size=2 >
Total 5 year cost of doing Traditional EDI. $215,000.00
</font><div>
<font size=2 ></font><div>
<font size=2 >(1)
You may be looking at additional VAN's dependent on the needs of the
trading
partner (customer).</font><div>
<font size=2 ></font><div>
<font size=2 >
Traditional EDI/XML Start up and operations for 5 year period also
assuming
no obsolescence of the </font><div>
<font size=2 >
translator, encryption package and assuming that you are only using web
communications with trading </font><div>
<font size=2 >
partners. All Trading partners are customers and SME will comply
across
the spectrum with all requirements</font><div>
<font size=2 >
placed on Them,</font><div>
<font size=2 ></font><div>
<font size=2 >1
Interface to Account's Payable 12,000.00 These
first
4
are labor costs</font><div>
<font size=2 >2
Interface to Account's Receivable 12,000.00</font><div>
<font size=2 >3
Interface to Purchasing 12,000.00</font><div>
<font size=2 >4
Interface to Order Processing 12,000.00</font><div>
<font size=2 >5
Purchase of the Translator 7,000.00</font><div>
<font size=2 >6
Purchase of a support package 5/8 2,000.00</font><div>
<font size=2 >7
Purchase of an Encryption Package (one time) 52,000.00</font><div>
<font size=2 >8
Purchase of Support 5/40 5,200.00 10% of
list
is
usual.
----------</font><div>
<font size=2 >
TOTAL Year One Start Up Costs 114,200.00 First
Year
Start Up.</font><div>
<font size=2 ></font><div>
<font size=2 >
Again figure about 1/2 of the development costs to maintain interface
through years 2 - 5.</font><div>
<font size=2 ></font><div>
<font size=2 >1
Interface to Account's Payable 6,000.00 These
first
4
are labor costs</font><div>
<font size=2 >2
Interface to Account's Receivable 6,000.00</font><div>
<font size=2 >3
Interface to Purchasing 6,000.00</font><div>
<font size=2 >4
Interface to Order Processing 6,000.00</font><div>
<font size=2 >5
Purchase of a support package 5/8 Translator 2,000.00</font><div>
<font size=2 >6
Purchase of Support 5/40 5,200.00 10% of
list
is
usual.</font><div>
<font size=2 >
----------</font><div>
<font size=2 >
TOTAL Cost years 2 through 5 36,200.00 Year two
through five costs.</font><div>
<font size=2 ></font><div>
<font size=2 >
Total 5 year cost XML/EDI via WEB.
$259,000.00</font><div>
<font size=2 ></font><div>
<font size=2 >
Combined traditional and web based EDI/XML system start up and operations
also assuming no obsolescence </font><div>
<font size=2 >
of the translator, encryption or other components. This model assumes
the
use of both a VAN and </font><div>
<font size=2 >
WEB based communications. All trading partners are customers and the SME
will comply with all requirements</font><div>
<font size=2 >
placed on them.</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >1
Interface to Account's Payable 12,000.00 These
first
4
are labor costs</font><div>
<font size=2 >2
Interface to Account's Receivable 12,000.00</font><div>
<font size=2 >3
Interface to Purchasing 12,000.00</font><div>
<font size=2 >4
Interface to Order Processing 12,000.00</font><div>
<font size=2 >5
Purchase of the Translator 7,000.00</font><div>
<font size=2 >6
Purchase of a support package 5/8 2,000.00</font><div>
<font size=2 >7
Purchase of an Encryption Package (one time) 52,000.00</font><div>
<font size=2 >8
Purchase of Support 5/40 5,200.00 10% of
list
is
usual.</font><div>
<font size=2 >9
Subscription to One VAN(1) 1,200.00</font><div>
<font size=2 >10
Byte Count for data transmission via a VAN 9,600.00 Cost varies
dependent on volumes of data.</font><div>
<font size=2 >
---------</font><div>
<font size=2 >
TOTAL Costs year 1 start up. $125,000.00 First
Year
Costs of Start up.</font><div>
<font size=2 ></font><div>
<font size=2 >
Again figure about 1/2 of the development costs to maintain interface
through years 2 - 5.</font><div>
<font size=2 ></font><div>
<font size=2 >1
Interface to Account's Payable 6,000.00 These
first
4
are labor costs</font><div>
<font size=2 >2
Interface to Account's Receivable 6,000.00</font><div>
<font size=2 >3
Interface to Purchasing 6,000.00</font><div>
<font size=2 >4
Interface to Order Processing 6,000.00</font><div>
<font size=2 >6
Purchase of a support package 5/8 2,000.00</font><div>
<font size=2 >8
Purchase of Support 5/40 5,200.00 10% of
list
is
usual.</font><div>
<font size=2 >9
Subscription to One VAN(1) 1,200.00</font><div>
<font size=2 >10
Byte Count for data transmission via a VAN 9,600.00 Cost varies
dependent on volumes of data.</font><div>
<font size=2 >
---------</font><div>
<font size=2 >
TOTAL COST, years 2 - 5 $ 42,000.00 Cost of
operations years 2 - 5</font><div>
<font size=2 ></font><div>
<font size=2 >TOTAL
COST 5 Year operations WEB/Traditional Combined $293,000.00 </font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >Mark</font><div>
<font size=2 ></font><div>
<font size=2 >-----Original
Message-----</font><div>
<font size=2 >From:
Dave Taylor [mailto:[EMAIL PROTECTED]]</font><div>
<font size=2 >Sent:
Tuesday, October 24, 2000 11:37 AM</font><div>
<font size=2 >To:
[EMAIL PROTECTED]</font><div>
<font size=2 >Subject:
Re: XML for EDI book: Any comments?</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >Andy,</font><div>
<font size=2 ></font><div>
<font size=2 >I
just talked with Cyclone about their EDIINT-compliant product and
they</font><div>
<font size=2 >quoted
me an annual license fee of $18,000 on NT or W2K, or a 1-time
charge</font><div>
<font size=2 >of
$52,000. It goes up for various flavors of Unix and even higher
for</font><div>
<font size=2 >OS/390.</font><div>
<font size=2 ></font><div>
<font size=2 >Do
you know of any less expensive EDIINT-compliant communications
solutions?</font><div>
<font size=2 >This
is pretty stiff for most small/mediuim size companies trying to
utilize</font><div>
<font size=2 >integrated
EDI.</font><div>
<font size=2 ></font><div>
<font size=2 >Dave</font><div>
<font size=2 ></font><div>
<font size=2 >-----
Original Message -----</font><div>
<font size=2 >From:
"Andy Sicignano" <[EMAIL PROTECTED]></font><div>
<font size=2 >To:
<[EMAIL PROTECTED]></font><div>
<font size=2 >Sent:
Tuesday, October 24, 2000 10:27 AM</font><div>
<font size=2 >Subject:
Re: XML for EDI book: Any comments?</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >>
Mark,</font><div>
<font size=2 >>
I like a lot of what you said in your post, but I disagree on two
points:</font><div>
<font size=2 >></font><div>
<font size=2 >>
1) XML may indeed facilitate communication between trading partners.
This</font><div>
<font size=2 >>
will require XSL transformation of messages. Although the W3C
standards</font><div>
<font size=2 >>
are settling down, we need solid implementations for this to become
a</font><div>
<font size=2 >>
reality.</font><div>
<font size=2 >></font><div>
<font size=2 >>
2) It is already possible to send secure EDI transactions over the
net;</font><div>
<font size=2 >>
we've been doing it for three years. It will probably become a
lot</font><div>
<font size=2 >cheaper</font><div>
<font size=2 >>
to do so in the near future, as vendors roll out products that conform
to</font><div>
<font size=2 >>
IETF's EDIINT AS2 specification.</font><div>
<font size=2 >></font><div>
<font size=2 >>
Andy</font><div>
<font size=2 >>
--------------------------------------------------------------------------</
font<div>
<font size=2 >-------------------------------------------</font><div>
<font size=2 >></font><div>
<font size=2 >></font><div>
<font size=2 >></font><div>
<font size=2 >></font><div>
<font size=2 >>
Mark Kusiak <[EMAIL PROTECTED]>@LISTSERV.UCOP.EDU> on
10/24/2000</font><div>
<font size=2 >11:45:35</font><div>
<font size=2 >>
AM</font><div>
<font size=2 >></font><div>
<font size=2 >>
Please respond to Mark Kusiak <[EMAIL PROTECTED]></font><div>
<font size=2 >></font><div>
<font size=2 >>
Sent by: Electronic Data Interchange Issues
<[EMAIL PROTECTED]></font><div>
<font size=2 >></font><div>
<font size=2 >></font><div>
<font size=2 >>
To: [EMAIL PROTECTED]</font><div>
<font size=2 >>
cc:</font><div>
<font size=2 >>
Subject: Re: XML for EDI book: Any comments?</font><div>
<font size=2 >></font><div>
<font size=2 >></font><div>
<font size=2 >>
The real truth about the XML vs. EDI is that XML is sexy. It's the
newest</font><div>
<font size=2 >>
thing to come down the pipe in a long while. As far as performing
"rip</font><div>
<font size=2 >and</font><div>
<font size=2 >>
read", it has merits and incentives for cost reduction that can
be</font><div>
<font size=2 >achieved</font><div>
<font size=2 >>
very quickly.</font><div>
<font size=2 >></font><div>
<font size=2 >>
Most PC workstations today have XML enabled browsers or can be
updated</font><div>
<font size=2 >with</font><div>
<font size=2 >>
them very quickly at next to nothing in cost. That means that the
XML</font><div>
<font size=2 >data</font><div>
<font size=2 >>
file can be displayed on the browser and made available to the direct
user</font><div>
<font size=2 >>
of the information without much intervention between the gateway and
the</font><div>
<font size=2 >>
user. It has the potential of getting data to the person who needs
it</font><div>
<font size=2 >>
rapidly. This is a real advantage of XML and should be exploited if
that</font><div>
<font size=2 >>
is the goal.</font><div>
<font size=2 >></font><div>
<font size=2 >>
Where XML falls flat is in true business system integration between
two</font><div>
<font size=2 >>
separate or remote computer systems. The use of the new standards (I
use</font><div>
<font size=2 >>
this term lightly as they are changing faster then you can shake a
stick)</font><div>
<font size=2 >>
will require that an interface be either built for the XML
centered</font><div>
<font size=2 >>
transactions or that the existing EDI interface programs be modified
to</font><div>
<font size=2 >>
handle the data provided. The second branch will be the method by
which</font><div>
<font size=2 >>
the implementation of XML happens.</font><div>
<font size=2 >></font><div>
<font size=2 >>
EDI has always been envisioned as the enabling technology to
allow</font><div>
<font size=2 >>
information from one computer in a company to be transmitted to
another</font><div>
<font size=2 >>
company, translated, and loaded to that companies application. All
EDI</font><div>
<font size=2 >>
affiliated professionals know that this is the true crux of costs
in</font><div>
<font size=2 >>
accomplishing the "computer to computer integration of information".
XML</font><div>
<font size=2 >>
has NOT solved this problem, unless it's cheaper to hire a clerk to
sit,</font><div>
<font size=2 >>
gather, and plug in what he/she sees on the browser (I feel that this is
a</font><div>
<font size=2 >>
huge step backwards).</font><div>
<font size=2 >></font><div>
<font size=2 >>
Most XML pundits believe that EDI cannot be communicated over the
NET.</font><div>
<font size=2 >>
Most managers believe the same thing. THIS IS FALSE. EDI data will
go</font><div>
<font size=2 >>
just as fast as XML data. The problem which has not been solved by
either</font><div>
<font size=2 >>
standard is that the data (invoicing and ordering) must be secure
between</font><div>
<font size=2 >>
the two companies. Not just the firewall, but the transmitted file of
data</font><div>
<font size=2 >>
moving across the nodes on the WEB. This means that a fast and
reliable</font><div>
<font size=2 >>
encryption must be used to ensure that the data is not sniffed in
the</font><div>
<font size=2 >>
middle. XML's promise of reduced communications costs are given at
the</font><div>
<font size=2 >>
sacrifice of security. Communications via a VAN allow me to have
an</font><div>
<font size=2 >>
organization which is reasonably secure from prying eyes. If it
happens</font><div>
<font size=2 >>
that the data is compromised, I have someone that can pay for the
damage</font><div>
<font size=2 >in</font><div>
<font size=2 >>
that the VAN is accountable. Over the net, I don't, so therefore I
must</font><div>
<font size=2 >be</font><div>
<font size=2 >>
accountable. Again, I want to stress that XML nor EDI have solved
this</font><div>
<font size=2 >>
problem. There are some heavy issues involved here. Not the least
of</font><div>
<font size=2 >>
which is the federal government here in the states. Until one can
encrypt</font><div>
<font size=2 >>
with impunity and the web can be rendered truly private, the reduction
of</font><div>
<font size=2 >>
costs for communications provided by the net will not be without some
real</font><div>
<font size=2 >>
compromises in privacy. Is this email moving via the web truly
private?</font><div>
<font size=2 >>
No, but I don't really care if Joe Sniffmeout in Cincinnati reads
this.</font><div>
<font size=2 >>
But, I'm not putting my credit card number in it either.</font><div>
<font size=2 >></font><div>
<font size=2 >>
Bottom line is that most people feel that the cost of
communicating</font><div>
<font size=2 >between</font><div>
<font size=2 >>
trading partners is the single largest cost of EDI. It is true that
the</font><div>
<font size=2 >>
cost is a variable and residual one that the controller or
responsible</font><div>
<font size=2 >>
manager sees. But that cost will be replaced by the costs to track
and</font><div>
<font size=2 >>
manage security encryption standards and the like. By going to
XML,</font><div>
<font size=2 >>
security costs will become a hidden one. No one will be able to
directly</font><div>
<font size=2 >>
determine them. It will not reduce the costs of doing e-commerce
with</font><div>
<font size=2 >>
others, it will just hide them. I doubt seriously that XML will
reduce</font><div>
<font size=2 >>
costs, it will more then likely raise them and e-commerce will
still</font><div>
<font size=2 >remain</font><div>
<font size=2 >>
as difficult to put in place as it was before XML ever came into
such</font><div>
<font size=2 >>
popular appeal.</font><div>
<font size=2 >></font><div>
<font size=2 >>
Mark</font><div>
<font size=2 >></font><div>
<font size=2 >>
PS. This is my opinion only. I've been involved in EDI/e-commerce
for</font><div>
<font size=2 >>
about ten years as a coordinator, analyst and implementation
resource.</font><div>
<font size=2 >></font><div>
<font size=2 >></font><div>
<font size=2 >></font><div>
<font size=2 >>
-----Original Message-----</font><div>
<font size=2 >>
From: Lee LoFrisco [mailto:[EMAIL PROTECTED]]</font><div>
<font size=2 >>
Sent: Tuesday, October 24, 2000 6:09 AM</font><div>
<font size=2 >>
To: [EMAIL PROTECTED]</font><div>
<font size=2 >>
Subject: Re: XML for EDI book: Any comments?</font><div>
<font size=2 >></font><div>
<font size=2 >></font><div>
<font size=2 >>
I'm a bit confused about the benefits of XML. In a traditional</font><div>
<font size=2 >>
EDI-intensive shop, where the supply-chain, time-critical
documents</font><div>
<font size=2 >>
are communicated electronically, and at a huge savings, where would
XML</font><div>
<font size=2 >>
improve this process? Granted, when communicating between a web site
and</font><div>
<font size=2 >>
desktop, XML has found a home. Entering a purchase order via a
web-based</font><div>
<font size=2 >>
entry screen, applying edits, and submitting the info to an ERP system
is</font><div>
<font size=2 >>
practical, cost-effective method of order processing for non-EDI
orgs.</font><div>
<font size=2 >>
But,</font><div>
<font size=2 >>
at some point along the way from entry to placing the order, the XML
file</font><div>
<font size=2 >>
needs to be translated to EDI (or some standard) before updating or
else</font><div>
<font size=2 >an</font><div>
<font size=2 >>
org would have to maintain an endless list of unique *maps* to
accommodate</font><div>
<font size=2 >>
all the variations. Now, that sounds like EDI to me.</font><div>
<font size=2 >></font><div>
<font size=2 >>
Without standards, which VP or Director is going to stake his or
her</font><div>
<font size=2 >career</font><div>
<font size=2 >>
on recommending changing from traditional EDI to XML? With millions
of</font><div>
<font size=2 >>
dollars invested in effort and resources with EDI, and with the
documents</font><div>
<font size=2 >>
flowing, why change? XML builds larger files and has yet to prove
itself.</font><div>
<font size=2 >>
If it ain't broke, don't fix it!</font><div>
<font size=2 >></font><div>
<font size=2 >>
Why all the hoopla about XML vs. EDI (unless of course it's from the
XML</font><div>
<font size=2 >>
software developers themselves)?</font><div>
<font size=2 >></font><div>
<font size=2 >>
Lee LoFrisco</font><div>
<font size=2 >>
Sterling Commerce Service Partner Consultant</font><div>
<font size=2 >>
VoiceMail: 614.210.2706</font><div>
<font size=2 >>
Cell Phone: 410.963.6218</font><div>
<font size=2 >>
eFax: 810.277.5002</font><div>
<font size=2 >></font><div>
<font size=2 >></font><div>
<font size=2 >>
-----Original Message-----</font><div>
<font size=2 >>
From: Electronic Data Interchange Issues</font><div>
<font size=2 >>
[mailto:[EMAIL PROTECTED]]On Behalf Of Glass, John K. III</font><div>
<font size=2 >>
Sent: Tuesday, October 24, 2000 7:16 AM</font><div>
<font size=2 >>
To: [EMAIL PROTECTED]</font><div>
<font size=2 >>
Subject: XML for EDI book: Any comments?</font><div>
<font size=2 >></font><div>
<font size=2 >></font><div>
<font size=2 >>
Hello group.</font><div>
<font size=2 >></font><div>
<font size=2 >>
I was browsing through some books at amazon.com and noticed a book
that's</font><div>
<font size=2 >>
supposed to be coming out in November called:</font><div>
<font size=2 >></font><div>
<font size=2 >>
Xml for Edi : Making E-Commerce a Reality</font><div>
<font size=2 >>
by Hussain Chinoy, Tyna Hull, Robi Sen</font><div>
<font size=2 >></font><div>
<font size=2 >>
I was wondering if anyone has preordered this book and if you
have</font><div>
<font size=2 >>
heard any buzz about what it will contain. You guys don't know of
any</font><div>
<font size=2 >>
other</font><div>
<font size=2 >>
books which dealt with this whole EDI/XML issue, do you? Anyway, any
info</font><div>
<font size=2 >>
that you have about this book would be appreciated.</font><div>
<font size=2 >></font><div>
<font size=2 >>
Thanks.</font><div>
<font size=2 >></font><div>
<font size=2 >>
=======================================================================</fon
t><dv>
<font size=2 >>
To signoff the EDI-L list,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >>
To subscribe,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >>
To contact the list owner: mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >>
Archives at
http://www.mail-archive.com/edi-l%40listserv.ucop.edu/</font><div>
<font size=2 >></font><div>
<font size=2 >>
_______________________________________________</font><div>
<font size=2 >>
Why pay for something you could get for free?</font><div>
<font size=2 >>
NetZero provides FREE Internet Access and Email</font><div>
<font size=2 >>
http://www.netzero.net/download/index.html</font><div>
<font size=2 >></font><div>
<font size=2 >>
=======================================================================</fon
t><dv>
<font size=2 >>
To signoff the EDI-L list,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >>
To subscribe,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >>
To contact the list owner: mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >>
Archives at
http://www.mail-archive.com/edi-l%40listserv.ucop.edu/</font><div>
<font size=2 >></font><div>
<font size=2 >>
=======================================================================</fon
t><dv>
<font size=2 >>
To signoff the EDI-L list,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >>
To subscribe,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >>
To contact the list owner: mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >>
Archives at
http://www.mail-archive.com/edi-l%40listserv.ucop.edu/</font><div>
<font size=2 ></font><div>
<font size=2
>
=======================================================================</fo
nt><div>
<font size=2 >To
signoff the EDI-L list,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >To
subscribe,
mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >To
contact the list owner: mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >Archives
at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/</font><div>
<font ></font></body></html>
--10114533-11930-972423508=:1012--
------------------------------
Date: Tue, 24 Oct 2000 18:17:01 -0500
From: A Hilton <[EMAIL PROTECTED]>
Subject: Re: XML for EDI book: Any comments?
Comments inline below...
>
> Now I am even more confused
>
I tend to have that effect. Sorry about that.
> What do you mean by *formatting structure*?
>
> X12 is the standard used , EDI is *the process* to route data?
>
I tend to break things down to it component levels so I can better
understand them and use them in my development projects. As such, I see EDI
as the process of getting 'documents' back and forth between computer
systems with as little human involvement as possible. This is broken down
into many different steps and procedures. To save space I just describe it
as a 'process' and believe that it is an ongoing one at that. So, yes, EDI
is "the process" that we as TP's go thru to get the documents flowing back
and forth in as automated fashion as possible.
The transaction sets are formatted to an agreed upon structure (and
supposed
'standard' like X12/EDIFACT for example). As we all know, these 'standards'
are merely starting points and templates for the large TP's to modify at
will. That's why we have part of the 'Process of EDI' to guide us on our
way
to a consensus on the actual and usable formatting structure that we'll use
with that TP. Now, XML can be added to this list of formatting structures
(X12/EDIFACT included) that could be used. It's just a different way of
encoding the documents. Once it achieves a certain level of usage then
it'll
magically become a 'standard' just like all the rest of the 'standards'
that
we have in the technology industry. <g>
> Are you saying that XML can use X12/EDIFACT standards? How?
>
I suppose you could wrap X12/EDIFACT formatting structures into XML tags
but
I don't see the big benefit of that. I've also used XML tags and a
hierarchical structure that mimick the X12 'tags'(Transactionset ID +
Segment ID, etc.) so that a few TP's could extract those XML tags into
'standard' X12 formatted files and work with them normally after that. It
was a comfort for them for awhile to do that. That's just one way to go
though.
> Doesn't XML use tags like http to identify the data? How is that X12?
>
Yes XML uses tags (delimiters) just as X12 uses ID's in the structure to
separate things. It's just that XML *can* (and that is a very powerful word
<g>) use tags for anything and everything and use, add, or ignore those
tags
at will. It's NOT X12. X12 isn't the only part of EDI either. It doesn't
need to be... it's just a data formatting structure. As long as those
structures are agreed upon by the TP's then it works.
I'm sure there are MANY resources that can explain it much better than I
can
out there. I just use both XML and X12 structures to fulfill my clients'
EDI needs. As I have found when discussing these things I have to say that
I
don't see any one format as the magic bullet. XML is just simply another
way
to do it and I find it very flexible.
- A Hilton
>
> On Tuesday, October 24, 2000 1:38 PM, A Hilton [SMTP:[EMAIL PROTECTED]]
> wrote:
> > For me, as a developer, the key to the XML formatting structure is
> > flexibility. The "Process of EDI" doesn't change with differing format
> > (X12/EDIFACT/XML-based). I would answer your original question
> by saying
> > that by having an XML-based EDI format will allow one to reach new
> partners;
> >
> > interact with new or existing partners in different and
> flexible ways; and
> > utilize new (and sometimes even effective <g>) automated processes to
> reach
> > your suppliers/customers. Does that sound enough like the verbage in
the
> > trade mags?
> >
> > Seriously though, I find the XML formatting structure of those clients
I
> > help 'do EDI' allows them to gain the benefits of the "Process
> of EDI" and
> > still have flexibility in how that data gets moved around. It really
is,
> in
> > my opinion, just a matter of moving bits around. The REAL work
> is in that
> > "Process of EDI" (as I like to call it... as you can tell) and
> it has very
> > little to do with the formatting structure.
> >
------------------------------
Date: Wed, 25 Oct 2000 15:07:37 +1100
From: "Wakelam Paul (RBAU/LOG)" <[EMAIL PROTECTED]>
Subject: Re: XML for EDI book: Any comments?
Greetings,
Mark's costs seem high.
1/ These costs seem based on new interfaces.
You should be able to sneak the data in by stealing the existing input and
output.
This means the system works very similar to what the user has used in the
past.
>1 Interface to Account's Payable 12,000.00 These first 4 are labor
costs
PW : Steal the data entery program and rewrite as a screen stuffer
with an error check report.
>2 Interface to Account's Receivable 12,000.00
PW : if it hasn't and interface use the output going to the invoice
print file.
If you only have the purchase order spool file, convert it and PERL
it to get the data.
Skip TT and payment as these are the minority of the transactions
and the major perceived audit risk.
3 Interface to Purchasing 12,000.00
PW : Use the output going to the purchase order print file.
skip quotes and requests for quotes.
4 Interface to Order Processing 12,000.00
PW : I havent seen a package for 5 years that hasn't got an
interface for customer order upload.
2/ The maintenance seems high
- Our interfaces use every field in the destination/origin file becuase we
found we were wasting time adding new fields.
This increased the inital costs but reduced our maintenence costs. We then
pcik and choose on our translator
- The translator costs seem low, and the SME seems to to be paying for it
in
high maintenance.
------------------------------
End of EDI-L Digest - 23 Oct 2000 to 24 Oct 2000 (#2000-242)
************************************************************
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
