While I must agree that XML will be replaced (history of technolgy in
general proves this theory), I wouldn't bet on it being anytime soon. As a
general note, XML is (in my opinion) not going to replace EDI. However, it
will replace EDI as the chosen format for startup companies. Unless someone
can give vaild reason for why a company should choose EDI over XML (or any
other format for that matter). Smart money says: go flexible, go XML.
Brian
-----Original Message-----
From: Rachel Foerster [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 29, 2000 5:32 PM
To: 'Kurt Cagle'; XML EDI Listserv (E-mail)
Subject: RE: Is the Internet/XML Going to Kill EDI?
Kurt,
First of all, I don't know why you sent your comments just to me. However,
I do think that this discussion deserves to be on the list, so I'm
going to post my response back to the XML/EDI list as well.
Just a couple of comments to yours below. I've inserted them at the
appropriate spot.
Rachel
|
|Rachel,
|
|First a disclaimer -- I'm not an EDI person, although I have
|worked with X12
|in a number of projects, but I have reached a point where I
|think I'm pretty
|much an expert on XML. While I do agree with you on a number
|of the points
|you bring up, I'd argue that your point about where we are with XML is
|pre-EDI. Consider this:
RF: I didn't say that XML is pre-EDI....I just said that XML and the
full suite of XML-related "standards" needs to mature in order to provide
much of today's capabilities that companies currently have with the
traditional
X12 or UN/EDIFACT standards. When these standards were first being
created they didn't explode out of the box as they are today. They were
developed and modified by many, many business domain and subject matter
experts to meet the business needs of the day. And, the beat goes on with
many
of these same people and others shaping and molding XML into what it must
be to meet the needs of business (commerce).
What I did say is that EDI is the electronic exchange of data....that we've
been
doing that for decades, even before the advent of the X12 or UN/EDIFACT
standards....
and that we'll being doing electronic data exchange long after X12,
UN/EDIFACT and, yes,
XML, have faded into the dim history of memory. It's just a new kid on the
block that needs to continuing growing and reaching maturity. It's not the
end-all, be-all of businesses exchanging information. It's just today's and
tomorrow's (for a while) tool. It too will be replaced and/or subsumed by
something else...bet on it!
|1) EDI had no notion of the concept of an encapsulatable transformation
|mechanism. XML has XSLT. While I think that the language
|itself still has
|some room for maturity, the ability to readily transform
|elements means that
|far from having immature dictionaries of tags, XML has largely
|transcended
|the need to have such a common dictionary in the first place.
|Thus, in many
|respects this is a HUGE advance.
RF: Of course EDI didn't include a concept of "an encapsulatable
transformation
mechanism" since that concept didn't exist when the early X12 standards
(let's not confuse EDI with the X12 and/or UN/EDIFACT standards) were
being created since the problem being addressed was the
application-to-application exchange of data. The basic concept of the X12
standards
is that since the X12 standard represents the common
language transformation is done only once by the sender (into the X12
standard)
and only once by the receiver (from X12 to internal format. XSLT only
provides a
mechanism for transforming one XML-formatted document structure into another
XML-formatted document structure.
|2) Up until recently EDI developers were only found in relatively large
|corporations because of the cost of access, and the tools for
|developing
|such applications were typically highly specialized and
|proprietary. XML is
|neither, meaning that the cost of entry of getting into B2B has dropped
|dramatically, the number of programmers specialized in those
|areas has risen
|accordingly, and there is far more synergy and evolution of
|B2B application
|theory as a consequence. When you have ten times the number of
|developers,
|the opportunities for developing better B2B solutions increase
|exponentially. Thus, I see the XML space as being far more
|evolved, dynamic,
|and flexible than EDI/X12 ever would be.
RF: I don't disagree with the above. I never said that XML was bad and X12
was good.
It's important to remember the context within which X12 was developed and
what
was available at that time (30 years ago). XML will most likely become much
more
predominate due to the greater accessibility of lost-cost/no-cost tools.
However, don't
confuse the fact that X12 developers were most often located within large
companies
with a lack of adoption. I developed PC-based systems that were provided to
over 5,000
customers in the late 1980's that used the X12 standards for purchasing, all
totally
transparent to the end-user (customer) who didn't even know that X12 was the
underlying data structuring rules employed. Furthermore, don't credit XML
solely with
your contention that "there is far more synergy and evolution of B2B
application
theory." This is due to a convergency of many technologies and capabilities,
not the
lease of which is the extention of the Internet to the masses with the
creation of Mosaic,
the World Wide Web, AND affordable and accessible telecommunications
services in
the U.S. XML is a johnny-come-lately to the tool-kit of electronic
information exchange
and complex computer networks. It's just the new kid on the block and he'll
have to
grow up just like every other technology.
|
|3) The VANs are faced with a fundamental problem --
|competition. With XML,
|the ability to create a competitive solution to the problem of
|EDI becomes
|more accessible to programmers, which means that the
|stranglehold that the
|VANs (such as EDS or related companies) have had has largely
|slipped away.
|Yes, the VANs provide value-added services, but so can any number of
|smaller, more nimble companies that have committed whole
|heartedly to the
|XML paradigm. As we move increasingly into a net services
|model, the only
|real advantage that the VANs have are longevity and relatively
|deep pockets
|-- both significant, but neither a guarantee in the more
|highly volatile
|markets of e-commerce.
RF: Don't confuse the Value Added Network (VAN) model with XML. XML
is ONLY a set of rules for tagging and structuring a document. It doesn't
at all deal with the transport of that document once it's created. I
developed systems and established X12 interfaces with thousands of
trading partner WITHOUT using VANs. VANs just simplied connectivity
for many large hub companies trying to connect with thousands of spoke
trading partners. Today the old EDI VAN model is morphing into the
Internet hub model, or marketplace, or exchange, or portal. VANs solved
a need at the time. The marketplace and their customers will tell them
when they need to transform themselves into something else.
|4) EDI is exclusively a commerce transaction format. However,
|one thing that
|people are beginning to recognize is that transactions involve
|more than
|just the exchance of commerce information. A medical XML
|infrastructure
|could handle everything from the storage of client care information to
|scheduling of procedures to data mining of traits for expert systems to
|billing, ordering and maintaining inventories of equipment and
|supplies.
|Thus its a more systemic solution, one that could in fact handle the
|complexities being applied to it. Moreover, the development of
|XML standards
|within the medical industry need to be developed by domain
|experts in the
|field, not by accountants working within the X12 paradigm.
|
RF: X12 is NOT exclusively for commercial (whatever you mean
by that) transaction format. There are X12 transactions that convey
all kinds of data that could be construed as non-commercial, such as
a First Report of Injury or Illness for workman's compensation
reporting, Organizational Relationships which is used to exchange
the structure, membership and relationship of organizations and/or
databases, such as a large hotel holding corporation or a purchasing
cooperative, or a database of entity identifiers. Also, lab test results
reporting, EPA reporting, and so on. These are just a few. As for your
assertion that XML will provide for the billing, ordering and maintaining
of equipment inventories and supplies or other clinical medical data,
you're off the mark. What will provide for those functions will be
the intelligent, automated business systems that apply and enforce
chosen business rules. Now, these system could and perhaps will in
the future, label the data used by these systems following the XML
rules, but systems like this are not dependent on XML to accomplish
their business mission. Lastly, XML-based vocabularies do need to be
developed and maintained by the business domain experts....but this
is already taking place on a fairly large scale, with RosettaNet, HL7
(for health care data), ACORD for insurance transactions, OTA for
travel and leisure transactions. I don't know what you mean by
"accountants working within the X12 paradigm." Have you
participated in the X12 Committee work? If you have, you would
know that the majority of participants are the business domain and
subject matter experts from there respective organizations. One would
only see the "accountants" for the work needed for some of the
financial transactions.
|The reason that I feel that these points need to be raised is
|that the XML
|market IS a little less established than the EDI/VAN
|infrastructure, and
|that self-same infrastructure has made a concerted effort to
|insure that
|people don't understand where the benefits of XML solutions do
|arise in the
|EDI sphere. The principle benefit of XML is that it is a democratic
|solution -- you don't need a significant investment for access
|of data, you
|don't need specialized tools for working with the data, you don't need
|specialized networks for transporting the data. Up until now,
|the VANs have
|controlled all three, but with the rise of open data standards that
|advantage is now largely lost.
RF: You're incorrect on all of your assertions above. The VANs have
not tried to keep people in the dark....they have been moving to
support XML for quite some time. However, remember, they have
a huge customer base that STILL USES THE X12 STANDARDS which
they still continue to support. Furthermore, the VANs have not
controlled the EDI/X12 software....sure, VANs provided software
solutions, but so do literally hundreds of other small to medium size
companies that do not provide VAN services. Where do you think
Mercator, NEON-PaperFree, DNS Worldwide, etc. to name a few,
came from? There never were and are not now VANs. Furthermore,
each of these, plus dozen's of other also support XML.
Also, you DO need specialized tools for dealing with XML-based
documents. What do you think the XML parsers are? Or the the
whole array of tools that can handle not only a well-formed XML document
but a valid document, plus use schemas, XSL, XSLT's etc. None of
this is done at the operating system level, which by the way, is just
another specialized piece of software, albeit an essential one.
When forced to compete
|essentially at the
|same level as the new players in the industry, they end up
|doing so with no
|significant advantages of the benefits, and not surprisingly are waging
|campaigns of disinformation about not just a change in standards but a
|paradigm shift in the ways that those standards are being applied.
RF: I don't know what "campaigns of disinformation" are being waged.
I haven't seen them. But, I do see all of the VANs that provided
traditional EDI/X12 services actively transforming themselves, offering
new types of services, and even participating (gasp!) with many of us
in the XML space to create the standard framework for XML so that
we will have interoperability....not the tower of babel and chaos that
exists today between all of the various domain-specific XML vocabularies
and/or company-specific vocabularies.
|I will doubtless generate heat with this message, but I get tired about
|hearing how the VANs are still the best way of doing B2B, that the XML
|standard is badly fragmented, and that we're worse off now then before.
RF: I don't know where you hear that VANs are still the best way for
business-to-business exchange of information. What you've been hearing,
at least on the XML/EDI and EDI-L lists, is that VANs are part of the
picture, offer services that may or may not be important to a company,
and that companies must determine for themselves what their requirements
are for the exchange of electronic information with their business partners
and to how best satisfy those requirements.
I have a bit tired of the VAN bashing....EDI was conducted for many years
without VANs. They came into existence to satisfy a customer/market
need and will go away when that need no longer exists. Rather than
getting so hung up about VANs why not start dealing with how you're
going to automatically process an XML-based purchase order when your
customer uses a tag like <PO#> and you use a tag like
<purchase.order.number>
and they use a tag like <Ship Date> and you use one like <Despatch Date>.
Just because these are human readable doesn't make them semantically
equivalent, and this is where the rubber hits the road.
Furthermore, I wouldn't be so eager to bash commerce. Afterall, it is
commerce (the buying and selling of stuff) that makes the world go around...
this has been so since the dawn of human beings and continues to be so.
Folks
did, do, and will continue to need to get stuff and in order to get stuff
they'll
have to exchange something for it. This is called commerce! It ain't so bad!
Rachel
|We're adapting to a new technology, one that will have an
|impact well beyond
|the domain of commerce, and as with any paradigm shift people are still
|learning how best to work with the new concepts. Many of the
|domain experts
|in EDI have made the shift to XML already, because they HAVE seen the
|advantages of the paradigm .... significantly, much of the
|shift of XML's
|focus from document to data has occured largely because of these
|individuals, who realized that the EDI standards simply had
|too high a price
|tag. Additionally, those same individuals understand that
|domain knowledge
|in the field of electronic commerce is more than simply
|knowing how to work
|with a specific program or set of field tags, and it is this
|expertise that
|gives them value in the new market. Does that mean that the
|EDI companies
|can survive with the model that they've been using for twenty years? Of
|course not.
|
|Okay, just my two cents worth.
|
|-- Kurt Cagle
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
