Dick,
Thank you for the background information and your comments, I enjoy these
discussions. I am working with the OAG, RosettaNet (less so) and most likely
ebXML in the future. In response to your statement
"what do you tell people who have an installed base of trading partners
using X12, EDIFACt or proprietary formats."
let me give you our current strategy perspective. First off, I agree with a
lot of your statements but I DO believe that XML is a plug-n-play technology
or at least a piece of it.
Continuing to use EDI (I'm generalizing) is OK if you are satisfied with the
cost of maintaining these interfaces, cost of developing new interfaces,
ability to reuse existing interfaces, speed at which you can add new
partners, opportunity for new types of business relationships. Lucent is
not. Some reasons being that it costs us lots of money to just maintain
existing interfaces. It costs of lots of money and time to develop new
interfaces. Reuse is nonexistent since a new EDI message must be negotiated
for each partner. Business relationships are limited to the scope of EDI and
existing trading partners, which means SME partners (a real value to Lucent
by the way) are out of the loop. EDI is not used for our internal
integration.
We want to establish a standard set of interfaces that we use for B2B
integration and that can be used without negotiation (a lofty goal I admit).
We are replacing existing EDI interfaces with XML interfaces (OAGIS). And
you are right, we have to convince our trading partners. In some cases we
are doing the work for them. The goal is not so much to turn down EDI, but
to get our act together. As I said earlier we have too many custom
interfaces which makes us slow to react to a changing business landscape. We
also want to establish a standard set of interfaces for internal A2A
(application-to-application) integration. Finally we want our internal and
external interfaces to be the same, so we can change the way we do business
by reconfiguring rather than re-implementing interfaces. Outsourcing
inventory for example, should not require a new interface to be developed,
just a reconfiguration.
I understand that XML is not the solution, just a part of it, and a rather
small part too. We have developed an architecture for plug-n-play
interoperability that shows the various layers required to support
plug-n-play. XML is the syntax we have chosen for the message. Other layers
include, structure of the message (i.e. OAG, RosettaNet, ebXML), business
information model (i.e. OAG, RosettaNet), message management for naming,
security, encryption (i.e. ebXML), horizontal content (i.e. OAG,
RosettaNet), vertical content (i.e. RosettaNet). That just covers the
message. The infrastructure has its own set of layers, messaging
infrastructure (i.e. the web), message routing interface (i.e. JMS, OAMAS),
directory services (i.e. LDAP), security (i.e. HTTPS, Certificates,
signatures), protocol (i.e. HTTP).
Finally, we are working with the OAG and RosettaNet hoping to bring those
groups together. We see a synergistic relationship between these groups, not
a competition. Likewise, with the emergence of ebXML I see more opportunity
for collaboration. There are a lot of things that need to come together and
no single organization can do it all. I hope the various groups can see this
and embrace the work of ebXML. Likewise I hope ebXML leverages existing work
and doesn't try to reinvent the yet invented XML-wheel.
Cheers,
________________________________________________________________
Kurt Kanaskie
Lucent Technologies
CIO Strategy, Planning & Architecture
[EMAIL PROTECTED]
(610) 712-3096
-----Original Message-----
From: Dick Brooks [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 21, 2000 6:52 PM
To: Kanaskie, Kurt A (Kurt); [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Article: Future of XML and EDI?
Kurt,
I suppose I'm to blame for the ad-hoc survey, which you recently responded
to. I think it only fair to give you some important background information
so that you will know where I'm coming from.
I work with both the IETF and ebXML groups in the creation/selection of
standards for transporting business documents (XML, X12, EDIFACT, whatever)
reliably and securely via the Internet. I also work with two standards
groups within the Energy Industry, the Gas Industry Standards Board (GISB)
and the Utility Industry Group (UIG) (responsible for standards within the
Electric Industry). Both GISB and UIG are seriously discussing XML and both
are trying to figure out how XML relates to X12 and existing
business-to-business transactions.
I've heard some people argue that XML should replace X12 because:
- translators are expensive
- people resist EDI(X12, EDIFACT) because it's complex and hard to
implement
- The little guy doesn't have the time, resources and talent to
implement
X12, EDIFACT
- XML supports both interactive and batch modes of interaction (the
best
argument in my opinion)
For those who have NO existing investments in B2B infrastructure (X12, or
other) I agree with you. Go with XML.
However, what do you tell people who have an installed base of trading
partners using X12, EDIFACt or proprietary
formats. In order to reap the benefits of XML they must convince their
trading partners to use XML. Changing to XML is not free either, even though
XML parsers are free and XSLT can be used to "translate" XML into flat files
someone still has to do the work to map the layout that drives the
translation. Alternatively, one could rewrite their backend systems to
accept/generate XML, but this is no small challenge for most. Perhaps one
day the XML-SQL gap will close and it will be easy for companies to go
between XML constructs and relational databases. I'm sure this will also
require some "wetware"/brainpower. No matter which way you look at it, XML
is not a "plug-n-play" technology, although some would like us to believe
this.
I don't want you to think I'm down on XML, because I'm not. I fully support
XML and our products already support XML. I think XML is an important
technology. But, I do see the daunting question facing many companies - Why
should they change to XML when it performs the same function as their
existing X12 systems. There has to be something "more" to convince people to
change. Again, for those with no sunk investments in X12, EDIFACT, then XML
is a no brainer - I agree.
There's more to the problem than simply the "format" used to represent data.
For example, if you could format your data
into XML today, how would you handle:
- Trading Partner profiles
- Stadnard Transport mechanism
- Privacy, authentication, integrity and non-repudiation
- Auditability
- Backend system integration
These are all issues which XML, by itself, does not address. What's needed
for a complete B2B implementation are products that implement functions for
all the above and support the range of formats your trading partners might
require (XML, X12, EDIFACT, et al).
Speaking as one of several members of the ebXML Message Routing and
Transport Group I can assure you that ebXML is attempting to solve some of
these issues as quickly as possible. Your inputs are always welcome.
Dick Brooks
co-author of IETF EDIINT AS2
member of ebXML Message Routing and Transport Workgroup
http://www.8760.com/
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kanaskie, Kurt
A (Kurt)
Sent: Monday, February 21, 2000 9:22 AM
To: [EMAIL PROTECTED]
Cc: '[EMAIL PROTECTED]'
Subject: RE: Article: Future of XML and EDI?
Hello,
I recently joined this list and these are the first messages I have received
on this topic. I would like to respond to some statements and the
questionnaire (pasted here near the top, comments are at the end of the
questionnaire.
Q1. Do you plan to replace your existing X12 tools/maps with XML
tools/interfaces?
Yes!
Q2. Please list the reasons for your answer to Q1?
Lower cost of use, via the Internet vs. VAN. Easier interpretation of the
message. A novice can read an XML message whereas some knowledge and effort
is required to decipher an EDI message. This means developers are more
likely to reuse an XML message than an EDI message. The mindset I have
encountered is, "it's easier to create a new message than to try to reuse an
existing one". Finally, and I know its clichi, but extensibility. A standard
XML message can be extended to support "particular" partners while not
requiring a complete new interface. This is due to the fact that all XML
fields are tagged, unlike EDI messages where some fields are packed.
Q3. For any "NEW" development, would you choose XML or traditional
EDI
(X12,
EDIFACT, etc.)?
Definitely XML!
Q4. Please list the reasons for your choice in Q3. (e.g. skilled
labor
pool,
sunk investments, cost savings, evolution etc.)
Cost of development, there are lots of web hackers out there that just love
XML. Faster implementation cycle due to lower learning phase. More business
opportunities due to open and standard XML messages.
Q5. Given the choice of transports would you choose a VAN or the
Internet
to transport your "EDI" (X12, XML, whatever)?
Internet!
Q6. Please list the reasons for your choice in Q5.
It is ubiquitous infrastructure, and we are already paying for it.
Personally, I believe XML has a bright future, but I'm not seeing
the
compelling reasons one would replace their existing
EDI with XML.
Money, money, money! Lucent spends quite a bit of money on the development
of new EDI messages and on the transport mechanism (VAN). Secondly, Lucent
does a lot of business with small business partners (suppliers, etc.) where
EDI is not a practical solution due to its cost. We do not want to impose
EDI on all of our trading partners. So, then we have two forms of B2B, EDI
vs. other-with-small-partners. To date the later has been done at the IT
developers discretion (i.e. Fax, automated phone, etc.). We see XML as the
key to bringing all of our B2B interfaces together with the obvious
advantages. Lastly I think the nature of EDI causes more interfaces to be
developed. Lucent has a very large number of interfaces that it uses both
internally and externally. We are working hard to lower this number due to
the cost of maintaining them. XML is the key in my mind.
But XML is not enough. XML is just the syntax, standards are required to
define the content. Currently there is no clear XML standard that the
industry has adopted, rather there are a lot of XML standards, which some
would interpret as, "therefore there are no standards". While this may be
true now, I don't expect it to continue. Lucent is very active in the (OAG)
Open Applications Group, which we are using in our current implementations,
and in RosettaNet. Ideally we want a single standard so we are working with
each of these groups to help bring them together.
Interestingly, I am leading a project within the OAG that is defining an
architecture for mapping EDI to OAG messages. The technical part is
straightforward (XSLT on an XML/EDI representation) but the semantic part
will be the most challenging.
I look forward to further responses and discussions on this topic.
BTW, is there an archive of this list somewhere. I don't want to rehash old
conversations.
Cheers,
________________________________________________________________
Kurt Kanaskie
Lucent Technologies
CIO Strategy, Planning & Architecture
[EMAIL PROTECTED]
(610) 712-3096
-----Original Message-----
From: Orin Rehorst [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 20, 2000 6:07 AM
To: [EMAIL PROTECTED]
Subject: RE: Article: Future of XML and EDI?
The answers below, "There is no XML standard," taken with "For each EDI
Transaction set, there must be an equivalent XML set of DTD's and/or
Schema's that are agreed upon," beg the question: "Is XML ready for industry
groups to build DTDs, schema, and get going with it?"
Orin Rehorst
Port of Houston Authority
-----Original Message-----
From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Sent: Sunday, January 09, 2000 7:04 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Article: Future of XML and EDI?
Q1. Do you plan to replace your existing X12 tools/maps with XML
tools/interfaces?
No, because right now, there is no XML standard.
Q2. Please list the reasons for your answer to Q1?
For each EDI Transaction set, there must be an equivalent XML set of
DTD's
and/or Schema's that are agreed upon in the industry I wish to do
business.
Not just on the fly made up to through the data at the trading
partner, but
industry-wide consensus and acceptance.
Q3. For any "NEW" development, would you choose XML or traditional
EDI
(X12,
EDIFACT, etc.)?
No.
Q4. Please list the reasons for your choice in Q3. (e.g. skilled
labor
pool,
sunk investments, cost savings, evolution etc.)
For the same reasons as in Q2
Q5. Given the choice of transports would you choose a VAN or the
Internet
to transport your "EDI" (X12, XML, whatever)?
The internet, using the internet to transport EDI, XML or whatever
is by
far the best method. But, your trading partner must be able to
receive the
data that way. If doing EDI via a VAN, then some investment in EDI
over
the internet must be made, if going to go with XML or a new
technology,
then your trading partner is probably capable or willing to invest
in the
Internet technology to make it happen.
Q6. Please list the reasons for your choice in Q5.
After initial investment, it is free. The initial investment is
well worth
the cost because it will be the communication method of preference
in the
future.
mtm
_______________________________
The EAN.UCC System
The Global Language of Business (tm)
Office: 609.620.4583
"Leary, John R"
<[EMAIL PROTECTED]> To: "'Dick
Brooks (E)'" <[EMAIL PROTECTED]>, Roy Roebuck
Sent by:
<[EMAIL PROTECTED]>, "XML EDI Listserver (E-mail)"
[EMAIL PROTECTED]
<[EMAIL PROTECTED]>
zserve.com cc:
Subject:
RE: Article: Future of XML and EDI?
01/09/00 06:31 AM
Please respond to "Leary,
John R"
Gents,
some philosophical comments of an early sunday morning:
-- what we have here are instances of "linguae francae" (see
Webster)
-- what is, is in a continuum; that is, as what will be, becomes,
what is
changes
-- EDI is 1050 / 5-channel papertape, is X12, is EDIFACT, is XML, is
XEDI,
is ebXML ...
-- as a language, XML is a carrier, and not intrinsically content
intensive
-- as a lingua franca, XML is fly-paper, and picks up all sorts of
useful
content (see XEDI.org)
-- as a language, EDI is rich in content, has several dialects, and
even
its
own tribe of keepers
-- as a lingua franca, EDI is like LATIN: syntax & content
controlled by
scribes, not by traders
-- just as Esperanto failed, and Swahili succeeded, XML will
flourish as a
lingua franca
-- chose XML for interacting with (new) suppliers because most (new
& old)
only speak lingua franca
-- an etymological pun: lets's be frank: whether a lingua franca is
"language of the franks", or "language of the frank" is immaterial:
it's
trade that makes the grade.
John Leary
-----Original Message-----
From: Dick Brooks (E) [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 08, 2000 2:39 PM
To: Roy Roebuck; XML EDI Listserver (E-mail)
Subject: RE: Article: Future of XML and EDI?
Roy, I disagree with your statement "that traditional EDI folks are
saying
"disregard the power and economies of XML and the Internet, and
continue to
use the expensive and proprietary EDI mapper software over expensive
and
proprietary VAN"."
In fact, over the past three years a significant number of companies
and
entire industries have migrated away from the VAN and onto the
Internet
because of the associated cost savings. The Gas industry began the
migration
to the Internet in 1996 and the Electric industry began the process
in
1998.
Organizations in these industries are transporting traditional EDI
over
the
Internet with great success, and I see no end in site to this
migration.
The resistance appears to be aimed at XML and not the Internet.
Companies
that have invested in X12 software and labor to create transaction
maps are
asking the question "Why throw everything away and replace it with
XML?".
This is a good question, IMHO. What does XML offer those who have
already
made the investment in traditional EDI technologies?
There's no question that a new implementor, with no history or sunk
investment, would find XML attractive (XML parsers are free, X12
translators
are not). But current implementors of X12 are having a hard time
seeing the
benefits of a replacement strategy, again IMHO.
It would be interesting to hear from list members who have
investments/implemented X12 with regard to
the following questions:
Q1. Do you plan to replace your existing X12 tools/maps with XML
tools/interfaces?
Q2. Please list the reasons for your answer to Q1?
Q3. For any "NEW" development, would you choose XML or traditional
EDI
(X12,
EDIFACT, etc.)?
Q4. Please list the reasons for your choice in Q3. (e.g. skilled
labor
pool,
sunk investments, cost savings, evolution etc.)
Q5. Given the choice of transports would you choose a VAN or the
Internet
to transport your "EDI" (X12, XML, whatever)?
Q6. Please list the reasons for your choice in Q5.
Personally, I believe XML has a bright future, but I'm not seeing
the
compelling reasons one would replace their existing
EDI with XML.
Dick Brooks
www.8760.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Roy
Roebuck
Sent: Saturday, January 08, 2000 11:09 AM
To: XML EDI Listserver (E-mail)
Subject: RE: Article: Future of XML and EDI?
Why do we continue to discuss XML versus EDI as though this were an
either/or issue? Isn't the whole issue of EDI versus XML versus
XML/EDI
resolving down to the application of syntax, semantics, and
messaging
medium
in the synchronous and asynchronous interchange of information? It
has
been
stated from the beginning of this group that we're seeking EDI in
combination XML. (In some reports to my clients, I've described
interchange
medium as "Carrier", interchange syntax as "Container", and
interchange
semantics (metadata) and information/data as "Content".)
For years, traditional EDI has invested much useful effort in
building up
an
organized and standardized body of interchange semantics (business
rules,
vocabularies/data-dictionaries, grammar, etc.) using the content
translation
syntax of various information/data mapping tools/methods to work
over a VAN
medium. XML has come out since 1996 providing a more powerful
content
mapping and translation syntax over the TCP/IP medium of the
Internet,
while
being semantically neutral. EDI via XML, in its many open and
proprietary
forms, seems to be seeking to move the rich semantic knowledge of
traditional EDI onto the syntax of XML over the Internet medium.
It seems to me that traditional EDI folks are saying "disregard the
power
and economies of XML and the Internet, and continue to use the
expensive
and
proprietary EDI mapper software over expensive and proprietary VAN".
This
hope that XML and the Internet will not globally usurp Traditional
EDI
syntax and medium is not realistic or rational.
Modern EDI: Semantics = Traditional Standard EDI Messages =
Information
Content
Syntax = XML = Information Container
Medium = Internet+Intranet+Extranet+VPN+VAN = Information
Carrier
Roy
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.com
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to
<[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.com
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to
<[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.com
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to
<[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.com
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to
<[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.com
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.com
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.com
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.com
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
