At 10:10 AM 1/31/2001 -0500, Yader, Mark (GXS) wrote:
>However, don't you think the platform vendors and the application vendors
>will continue to support XML standards, with the eventual outcome that B2B
>and A2A will be alot easier (and cheaper) ?
No I don't. XML will develop transactions standards just as X12
did. However it is the flexible use of that standard that presents the
problem. This occurs in XML just the same as in X12. It has nothing to do
with the formatting of the data. It has to do with the need of businesses
to compete and thus to use a better model and to tweak an existing
standard. This is what is so expensive labor wise for the SME's.
The idea of a "standard" PO or ASN is a myth and will never happen in a
competitive worlds. this is the same myth that troubles any exchange of
business documents regardless of format (X12, XML, etc).
>
>You didn't mention any specific XML standards in your e-mail......I'd be
>interesting in hearing your experience/views with RosettaNet and its impact
>on your company and others in Silicon Valley.
Four groups at Cisco use RosettaNet mine included. Three groups use custom
modified PIPs. My group created our own entire PIPs as there were none
from RosettaNet. We are using RosettaNet's RNIF 1.1 transport protocol
with https. Implementation rates seem to be a year plus. One one trading
partnership is in production
>
>Mark Yader
>GE Global eXchange Services
>
>-----Original Message-----
>From: Steve L. Bollinger [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, January 31, 2001 12:13 AM
>To: [EMAIL PROTECTED]
>Subject: The XML/EDI has no Clothes!
>
>
>
>
>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/xmledi-group@disa.org/msg00256.html
><http://www.mail-archive.com/xmledi-group@disa.org/msg00256.html>
>
>http://www.mail-archive.com/xmledi-group@disa.org/msg00496.
><http://www.mail-archive.com/xmledi-group@disa.org/msg00496.html> html
><http://www.mail-archive.com/xmledi-group@disa.org/msg00496.html>
>
>http://www.mail-archive.com/xmledi-group@disa.org/msg00571.html
><http://www.mail-archive.com/xmledi-group@disa.org/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
><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=>
>http://www.ecomworld.com/magazine/focus/default.cfm?Topic=>
>By Peter Lucas
>< <http://www.ecomworld.com/search/author/byauthor.cfm?AuthorID=132>
>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
------ 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
