Hi all!
I am sure you all remember the story of the little boy who walked up to the big imposing Emperor and said "Hey mister, how come you're naked?". Well, I now don't have to feel like that little boy anymore.
Seven months ago I began participating in the [EMAIL PROTECTED] mail list by writing and responding on various threads. The basic thrust of my arguments evolved over a period of a few months and finally came to be that the use of XML as a format to replace traditional EDI such as X12 and EDIFACT was not only quite over hyped as a solution, but was actually in some ways a regression and not a progression. This is a view I still hold after working 9 months on an XML/EDI project for a major Silicon Valley firm. A few of my views in detail:
http://www.mail-archive.com/[email protected]/msg00256.html
http://www.mail-archive.com/[email protected]/msg00496.html
http://www.mail-archive.com/[email protected]/msg00571.html
I did get some support from members of this list, mostly in private emails to me. Being very politically incorrect for Silicon Valley, there was only moderate open agreement. Until now, I have never seen any support for my positions in any of the computer, trade or business magazines. All I ever saw were more hyped, rosy predictions for XML/EDI and how the payoff of getting the smaller players involved (big problem with EDI) was just a few years around the corner. Last week's article by Peter Lucas in Electronic Commerce World magazine changed all that. He points out the many problems with XML/EDI now. I have included below, Peter's article, the magazine links and an article summary. I predict a growing trend in such articles in the coming months.
I consider Peter's article a good start in informing people of the difficulties of XML/EDI and popping the hype bubble. I say start because although Peter does a good job in pointing to the problems that are occurring in XML/EDI, he attributes these to lesser issues such as lack of transaction standards and other things. I think he has yet to fully grasp the biggest underlying causes of these issues and their magnitude. He says EDI went through the same sort of lack of standards in their earlier years and XML is suffering the same growing pains.
While this is true enough, Peter needs to investigate a bit further and discover that in EDI the really BIG problem is that of "differing trading partnerships". This is a labor intensive problem especially for the smaller vendors trading with larger customers formatting for each one of their standards. Even with a standard PO (X12 850), there are many optional elements making many possible flavors of 850. It leaves EDI to the 20% and excludes the 80% that ought to be benefiting from EDI because the programming services become too expensive to integrate EDI to the back-end ERP or accounting software.
This is the actual problem that is keeping the little player out of EDI. Worse yet, this is going to be an even BIGGER problem in XML with different tag structure, not less of a problem. I am still waiting for the trade magazines to talk about THAT! Regardless, Peter's article is a great start and I applaud him for beginning to unclothe XML/EDI. I don't have to feel like the lone voice in the wilderness anymore!
Long live the Emperor! :)
Steve Bollinger
Cisco Systems -- B2B Inventory Project
P.S. Just a few hypothetical questions: How much has this over hype of XML lead to the down turn in B2B companies in the past 10 months? How much has the down turn in B2B after it's rosy forecast, contributed to the current US economy down turn? Maybe our own foresight (or lack thereof) has lead us to our own currently sucky stock options? Just some thoughts.
Remember that a big part of consumer confidence comes from vendors who produce good and workable products and solutions. We as technologist have a duty to have enough foresight to lead our customers and the companies we work for, down a path of sound technological solutions that will actually work long term. I think we all as techies have definitely gone astray on this one issue of XML/EDI as the solution to traditional EDI problems.
Opposing and supporting views are welcomed. Come on, let's have some more rip-roaring debates like we did last summer, remember?
============================================================
Summary: After several years of working with XML, end users are discovering
that its structural simplicity has spawned a multitude of dialects. The
result is a mind-boggling array of syntaxes and vocabularies within vertical
markets that make XML document translation extremely difficult. This lack of
standards is creating constant headaches for chief technology officers and
their IT staffs. The basic cost of integrating an XML application into an
existing platform (exchange) runs between $500,000 and $1 million and takes
six to 12 months. Competition to establish a standard has already started.
Like Oasis, the World Wide Consortium (W3C) is striving to establish
building blocks for structuring XML standards that can be adopted across
multiple industries.
http://www.ecomworld.com/online/columns/read.cfm?contentid=381
Article published 01/22/01 on Ecomworld.com
Technologists Debate the Best Way to Implement XML
<http://www.ecomworld.com/magazine/focus/default.cfm?Topic=>
By Peter Lucas
<http://www.ecomworld.com/search/author/byauthor.cfm?AuthorID=132>
Report from EC Technology News:
Since its debut in the late 1990s, XML has been touted as the data exchange
language standard that will revolutionize business-to-business e-commerce by
enabling even the tiniest companies to communicate with any trading partner
via the Internet.
The rationale for this hype lies in the fact that extensible markup
language, or XML, was created for use over a public network, rather than
proprietary networks. That spares small companies from having to invest
their limited IT resources in building direct links to multiple trading
partners or trading exchanges.
In addition, structures defining XML documents are inherently simpler. The
basic structure for a purchase order, for example, requires a header,
trailer and middle body that usually feature repeatable data fields. The
structure is so simple that e-mail can qualify as an XML document. But
after several years of working with XML, end users are discovering that its
structural simplicity has spawned a multitude of dialects. The result is a
mind-boggling array of syntaxes and vocabularies within vertical markets
that make XML document translation extremely difficult. This lack of
standards is creating constant headaches for chief technology officers and
their IT staffs.
Although XML implementation issues are more organizational in nature than
technical, they remain daunting. "People buy into XML on the promise that it
will be a panacea, but multiple versions are springing up because it is too
easy for companies to create proprietary XML standards," explains James
Paat, founder and chief executive officer of EC Outlook, a Columbus,
Ohio-based provider of XML translation solutions. "Companies are starting to
fear a translation problem with XML-and that is going to slow its adoption
rate."
Some of the problems between XML formats are data fields of varying lengths,
a lack of rules for handling transmission errors, and difficulty in mapping
a trading partner's identification code and password to the hub that
operates the trading network.
Varying field lengths pose a major problem because each trading partner uses
a predetermined set of characters to define each data field. Lack of
continuity between data fields means that trading partners will have either
too few or too many characters to define an item in the field. That can make
XML translation difficult, even within vertical markets where standards are
expected to exist.
To address the problem, some companies are creating proprietary translation
tables for each partner's XML syntax. These tables define the characters
that appear in each corresponding data field so each partner can read the
other's document.
"We do a lot of brute force translation," says Ted Tritchew, product manager
for Pleasanton, Calif.-based Ironside Technologies, which uses XML to
communicate with trading partners. "So many of the dialects we deal with are
verbose, which makes it tough to understand the language." The absence of
rules for handling transmission errors is no easier to manage. Since the
Internet is a public network, secure transport of information is not
guaranteed. Documents can be garbled as they flow through the network or
even compromised by hackers. Because XML translation is already difficult,
detecting an error is even tougher since error and receipt codes do not
always accompany a document. And if they do, the recipient may not be able
to translate them.
"There really is no way to validate the data tags until you try to part
them, if you can," says Steven Dobson, a software engineer for Ironside
Technologies. "Authentication and validation problems are likely." So is
mapping a trading partner's ID and password from the spoke system to the
network hub. Addressing this issue requires mapping the users' system to the
hub and vice versa. "It is a time-consuming and costly process," adds
Dobson. The basic cost of integrating an XML application into an existing
platform runs between $500,000 and $1 million and takes six to 12 months,
according to EC Outlook.
Since many trading exchanges may support as up to 20 XML formats, several of
which may have a few common syntaxes, but not enough to warrant a standard,
the price tag for XML applications can be a deterrent. This high cost may
force many small trading partners to be more selective about who they
communicate with using XML, which in turn will stunt XML's growth. In a
worst case scenario, the high cost of XML may sideline small companies from
participating in a trading exchange altogether.
Another shortcoming of XML is difficulty in communicating with foreign
trading partners. The problem is the result of many XML documents being
created using eight-bit ASCII codes, which only support 256 definitions per
character and thus only a limited number of foreign languages, according to
Dobson.
To overcome this problem, Ironside uses Unicode, an 18-bit coding language
created by Microsoft Corp, Redmond, Wash. Unicode supports 64,000
definitions per character and can translate documents written in almost any
language. "Otherwise you may get garbage for character recognition in
dealing with documents created in foreign countries," Dobson says. XML
proponents counter that companies creating XML documents in eight-bit
formats are using XML improperly. "XML was conceived to universally support
multiple languages through Unicode," says Norbert Mikula, chairman of the
technical advisory committee for Oasis, an industry association attempting
to define XML standards. "It makes no sense to use an eight-bit ASCII code
to create an XML document," he says.
Blame it on marketplace confusion. The inability to steer vertical markets
toward an XML standard and the implementation problems that have grown out
of the situation are so great that few end users report success with XML.
During a recent panel discussion, one industry executive asked how many
audience members had success using XML. "Only a few hands were raised," says
the executive, who requested anonymity. "The response was that when it
worked, it was a miracle. Expectations about what XML can do need to be
tempered until there are standards."
Implementation issues resulting from the lack of XML standards are
symptomatic of a lack of structure for data fields in XML documents,
according to Rita Knox, an analysts and vice president for Stamford,
Conn.-based GartnerGroup. "Everyone who uses XML speaks the same language,
but there are no rules on how to define the grammar or structure the
sentences," she says.
The syntax or structure of an XML document is defined in three ways: an
entity within the document itself; a schema, which is a separate XML
document; or separate non-XML documents known as document type definitions
(DTDs). While entities are easy to edit, they are localized. That makes them
difficult to use in exchanging multiple documents with the same syntax,
because the XML application must reread the syntax descriptions for each
document transmitted. DTDs and schemas are more user friendly because they
can be referenced by many documents, even those residing on remote servers.
Many efforts to establish XML syntax standards focus specifically on schemas
because they deliver richer data in a more flexible format. But settling on
a common schema is not expected to happen anytime soon.
"Resolving this problem could take a couple of years," Knox predicts.
"Computers do not know how to reconcile different characters in a data field
unless they have a translation map agreed upon by the parties exchanging the
document."
One reason XML experts predict it will take years to establish a schema on
which vertical markets can establish standards is that few XML developers
write applications on a modular basis. That prevents end users within a
vertical market from being able to share common characteristics of their XML
formats and build a single standard, according to Oasis' Mikula. "Formats
do overlap, but unless a format is modular, you wind up having to build a
standard from the ground up, rather than merging the compatible pieces," he
says. "That equates to constantly having to reinvent the wheel to achieve a
standard."
Competition to establish a standard has already started. Like Oasis, the
World Wide Consortium (W3C) is striving to establish building blocks for
structuring XML standards that can be adopted across multiple industries.
Issues likely to be addressed by W3C are data types used within a document
and length of the data field, according to XML experts. Such definitions
will put constraints on presenting data as a simple text stream by defining
the vocabulary with the data field.
"People need to move from trying to define data fields to defining
vocabularies," says Knox. "The idea is not to create new definitions but to
use the ones we have within the appropriate fields." In the interim, many
small companies that rely on XML are turning to third-party service
providers to translate documents exchanged with their trading partners.
Service providers serve as interpreters, relying on huge databases of XML
style sheets to edit a document using the business rules established by the
receiving company so that the document arrives in a readable format.
The rapidly growing list of service providers includes Ironside
Technologies, Cambridge, Mass.-based PFN and St. Paul, Minn.-based SPS
Commerce. Providers of enterprise relationship management software that
offer various types of translation applications, such as Atlanta-based
Redcelsius, also are attacking the market.
While third-party translation and application providers help to bridge the
gap between disparate XML dialects for many companies, one drawback to their
presence in the market is that they create proprietary translation
templates. Some industry observers argue that this approach is another step
away from achieving vertical market standards.
But for many third-party service providers, the decision to develop their
own XML schemas is a matter of going with what they know will work, rather
than betting that another developer's schema will prevail. "There is a lot
of clamoring for standards, but few companies are flexible enough to adopt
other XML standards," says Keith Kohl, director of product management for
PFN. "If someone says a standard exists, at this stage of the game you have
to ask whether it is fully baked. A lot of hubs are not sure what standards
to use. If they want to be neutral, they end up choosing their own
standard."
Ultimately, standards across vertical markets are expected to emerge, just
as they did with EDI, but getting there is expected to be just as painful.
"In the 1970s, EDI was expected to be a cure-all, but it took a long time to
establish standards," recalls EC Outlook's Paat. "It is not surprising that
the same thing is happening with XML."
If XML standards are to be established, end users must begin writing XML
applications with interoperable modules. "When that happens, we will achieve
plug-and-play status," predicts Donna Fluss, chief strategy officer for
Redcelsius. In the meantime, CTO's must continue to brace for the throbbing
headaches related to implementing XML applications.
Peter Lucas
Peter Lucas is a freelance journalist based in Highland Park, Ill.
------ 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
---------------------------------------------------------------------
Plan on attending the upcoming meeting during DISA's conference:
http://www.disa.org/conference/annual_conf/index.htm
