I have to say that I agree with Rachel's comments around 98% which is a far
higher rate than most political agrements !
In answering Brian's question - the reason why most companies will chose
more traditional methods of EDI over XML in the short to the medium term is
that most of the buying companies have legacy systems that pre-date XML
and, in the world of EDI, "Buyer Rules OK" !
Also agreeing with Rachel - XML today is, in some ways, a backwards step as
its latent flexibility encourages parochial systems which is precisely what
X.12, UN/EDIFACT et al at least part way overcame.
Remembering that, even with XML, it is the buyer that decides the formats
etc, all of the XML implementations that I have seen to date offer the
supplier an even more confusing situation. He has to learn new methods,
new operations, new formats etc etc for each of his buyers. Back to paper
but worse ! At least in the traditional EDI world he could have a front
end that dealt with the variations on a theme - with XML he is invariably
told to "log into my site - it's XML based so its standard" then he finds
the reality.
Folks - I sat on various committees in the mid 80s and gamely pronounced
that UN/EDIFACT was going to offer true standardisation. I believed it, I
soon woke up, but it (or X12) is better than what went before.
XML has the potential to be better than UN/EDIFACT but we are still a long
way away and we need much less hype and much more work on standardisation
before it is anybody's saviour. With standardisation where it matters and
flexibility where it does not - then we could have a real winner.
Let's all work together towards "EDIML" as the working manifestation of the
"language" of XML.
Regards
John Sanders
PS. Please no more EDI or XML - XML is a facilitator for EDI the same as
UN/EDIFACT, X12 or ..... !
At 01:52 2000-07-30 -0700, Brian Curtis 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
------ 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
