Brian,
As an addition to your reflections:
EDI being the "electronic exchange of data based on
agreed standards", I don't think it will ever
disappear. What I think we are witnessing now is the
technology transition from EDI proprietary translators
and application integrators/VAN transmissions to the
XML open parsers and open integration
standards/Internet transmissions.
Paul
--- Brian Curtis <[EMAIL PROTECTED]> wrote:
> 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
>
>
__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
