Who said you can’t teach an old dog new tricks. (or Bill’s view of the wonderful world of XML)

1. XML for EDIers Who said you can’t teach an old dog new tricks. (or Bill’s view of the wonderful world of XML) Bill Cafiero 972-231-2180 jcaf@airmail.net

2. Credits • My thanks to the following experts for contributing ideas, material and advice in the development of this material: • Bob Angrisano, Microsoft Corporation, for the style sheet examples • Joe Kellett, Legendary Systems, for much of the XML vs EDI material • John Ousterhout, Scriptics Corporation , for the XML application integration discussion • Any errors or omissions introduced into their material are solely my responsibility • Bill Cafiero

3. Session Outline This Session has five sections: 1. Introduction - Why XML? 2. Technical Section - For the “Pony Tails” - the mechanics of XML 3. Current Standards Development Section - What work is underway at the present 4. The Role of XML - For the “Grey Hairs” - Where XML might fit in B2B commerce 5. Observations for the EDI Professional A good web site for general XML information is www.xmlinfo.com An XML Tutorial may be found at www.ge.gxs.com

4. EDI is “B2B” (Business-to-Business) electronic business process integration, fine-tuned by knowledgeable and talented people over many years, and it works now. Rich and sophisticated business semantics. Mature supporting technologies. Reliable. Large available pool of technical talent. So why “reinvent the wheel” with XML? The promise is: Faster time-to-market for TP connectivity, faster end-to-end communications. Cheaper to create and maintain TP relationships. Better quality of TP relationship, since XML “extensibility” makes it easier to design and implement new solutions. Section 1 - Why XML?

5. EDI was designed when storage and network costs were more important factors, and is therefore “cryptic” and “hard to understand”. This “cryptic” quality also means that specialized stand-alone translation software is required. It is quite impractical for business applications to be programmed to “speak and understand” EDI natively. Therefore a specialized staff is required who understands the cryptic encoding methods used, and who can program (“map”) the specialized software. A “specialized staff” means development bottlenecks and training/recruitment issues. EDI Tradeoffs

6. At runtime, the required translation software is also a point of delay, and sometimes a point of failure. High-level business process exchanges are only loosely standardized. High-level business-process analysis and design is required for each TP relationship (at least for the non-dominating partner). EDI “standard” documents are highly configurable - no two need have the same structure. Therefore, lower-level data analysis and design is also required. The final custom design must be custom programmed (“mapped”) by the specialized staff on the specialized software. In other words, a one-off custom software development effort is required to bring up a TP relationship. EDI Tradeoffs

7. “EDI or Die” never happened and never will. Some industries are so time-constrained and interaction-rich that EDI did become a survival requirement. Big hubs love EDI for its cost savings; they enjoy economies of scale that easily recoup EDI investment. Everyone else resists EDI unless forced because their cost/benefit ratio is too high. “EDI or Die”? XML to the Rescue???

8. Section 2 - For the “Pony Tails” Let’s look at the details of XML...

9. XML Highlights • Data that in X12 is defined by its position in a predefined structure is, in XML, given a label (tag) that describes the data in the transmission itself. • <Price>9.95</Price> This is the essence of XML!

10. Internet HTML XML Java Where Does XML Fit? platform presentation The Internet creates a need for platform-independent technology. data processing

11. An Order in XML • <?xml version="1.0"?> • <!DOCTYPE Order SYSTEM "Orders.dtd"> • <Order> • <Order_Number>1001</Order_Number> • <Order_Date>04/24/00</Order_Date> • <Customer>Bill's Supply Company</Customer> • <Detail> • <Line_Number>1</Line_Number> • <Item>A-123</Item> • <Quantity>10</Quantity> • <Price>1.50</Price> • </Detail> • <Detail> • <Line_Number>2</Line_Number> • <Item>B-987</Item> • <Quantity>20</Quantity> • <Price>2.00</Price> • </Detail> • <Shipment> • <Shipment_Number>1</Shipment_Number> • <Ship_Date>3/15/00</Ship_Date> • <Shipment_Detail> • <Line_Number>1</Line_Number> • <Quantity>10</Quantity> • </Shipment_Detail> • <Shipment_Detail> • <Line_Number>2</Line_Number> • <Quantity>15</Quantity> • </Shipment_Detail> • </Shipment> • </Order> • Orders • Order_Number • Order_Date • Customer • Detail • Line_Number • Item • Quantity • Price • Shipment • Shipment_Number • Shipment_Date • Detail • Line_Number • Item • Quantity • Price • Shipment • Shipment_Number • Shipment_Date • Shipment_Detail • Line_Number • Quantity • Shipment_Detail • Line_Number • Quantity

12. Simple XML Document Processing Sender’s Application Generates XML Purchase Order • <?xml version=“1.0” ?> • <Purchase_Order> • <Order-Type> newOrder = “True” Quoted = “Yes”/> • <Bill-To> • Bill-To Info • </Bill-To> • <Ship-To>Ship-To Info<Ship-To> • <Line-Item>Line Item Info</Line-Item> • <Line-Item>Line Item Info</Line-Item> • <Terms>Some Payment Terms</Terms> • <PO-Total>PO value info</PO-Total> • </Purchase_Order> Sender Sends to Receiver Receiver Receiver Application processes PO • <?xml version=“1.0” ?> • <Purchase_Order> • <Order-Type> newOrder = “True” Quoted = “Yes”/> • <Bill-To> • Bill-To Info • </Bill-To> • <Ship-To>Ship-To Info<Ship-To> • <Line-Item>Line Item Info</Line-Item> • <Line-Item>Line Item Info</Line-Item> • <Terms>Some Payment Terms</Terms> • <PO-Total>PO value info</PO-Total> • </Purchase_Order> XML Parser executes and checks for well-formed document and if OK, creates PARSE TREE Receives PO Passes to XML Parser PARSE TREE to application

13. Orders.xml Parsed http://msdn.microsoft.com/xml/notepad/intro.asp

14. Viewing XML • What about displaying XML documents? • XML itself does not describe how a document is to be displayed for human interpretation (i.e., screen, paper, audio) • XML documents are just plan text files - you use a text editor to create and view them but there’s no formatting • Internet Explorer 5 and Netscape Communicator 6 browsers will handle XML directly.

15. Style Sheets • What is a Style Sheet? • You can combine a style sheet with an XML document to display the document • Style Sheets contain the rules that declare how the document’s information should appear • Style Sheets are like “templates and styles” in MS Word • Extensible Styling Language (XSL) is the language of Style Sheets

16. art.xsl The Power of Style Sheets table.xsl bar.xsl

17. ie5.xslie4.xslnav3.xsl edi_x.xslsap_y.xslflat_z.xsl Use the Same Data Multiple Ways nokia.xslsony.xsl

18. XML Processing XSL Style Sheet Web Browser XML Parser XSL Processor DTD Other (e.g. Directly into Application) XML Data Source

19. Why use XML for E-Commerce?: XML bridges the gap between traditional EDI and Web-based applications. Most of high-tech industry has espoused XML: Virtually all new software from Microsoft, GE Global eXchange Services, Netscape, IBM, and others are going to be enabled to use XML. XML could make EC/EDI more available to the SME and other non-traditional EDI users. Section 3Current Organizational Developments Many approaches are under development:

20. Sampling of Current Initiatives • XML/EDI • Open Applications Group Integration Specification (OAGIS) • Collaborative Planning Forecasting and Replenishment • Open Trading Protocol (OTP) • Open Financial Exchange (OFX) • Commerce Interchange Pipeline (CIP) • SAP’s BAPIs • IE and Netscape browsers • MS-Office • DLA Emall • Extensible Forms Description Language (XFDL) • Common Business Language (CBL) • Web Interface Definition Language(WIDL) • Bank Internet Payment System (BIPS) • XML Metadata Interchange (XMI) • Simple Workflow Access Protocol (SWAP) • Information Content & Exchange (ICE) • Interactive Electronic Technical Manuals (IETM) • Standard Exchange for Product (STEP) • Organization for the Advancement of Structured Information • etc., etc., etc...

21. ebXML ebXML • The ebXML Approach • Adopt existing specifications where appropriate • Utilize what worked in EDI • Understand the underlying reason for failure in EDI • Bridge needs for application-to-application versus application-to-human • The approach supported by ANSI ASC X12

22. Section 4The Stuff for the “Grey Hairs” XML and EDI Where will XML fit in B2B EC? How will XML and EDI interact?

23. XML-EDI Visualized NOT ENOUGH! < XML > + EDI Syntax and Standards

24. What XML does for B2B: Format for data interchange Standard protocols for trading communities CXML: Ariba RosettaNet What XML can’t do for B2B: Integration with enterprise resources Business rules XML and B2B

25. What XML Doesn’t Provide Integration Translation Business rules Management XML Infrastructures Database Internet EAI or Enterprise Middleware ?? XML XML-enabled Application Non-XML Application

26. Where XML Might fit • Enterprise Application • Integration (EAI): • Apps within Enterprise • Application Server: • Browsers over Internet • XML Integration • Server: • B2B over Internet

27. Section 5Observations for the EDI Professional What does all this mean to the EDI Professional? Is EDI Dead?

28. XML proponents think they’re going to dramatically reduce the expense and time-to-market factors associated with EDI. Also, the “XML vision” sometimes goes far beyond “B2B” to include revolutionizing the way all electronic process interfaces are done. The XML “Utopia to Come”… Faster Cheaper Better XML Utopia

29. “There Ain’t No Such Thing As AFree Lunch”. XML document standards aren’t shaken out yet. And for quite awhile you’ll still have your existing non-XML-speaking back-end systems. Most applications won’t speak XML natively for quite awhile. Too many rapidly evolving “standards” for one thing. So the XML analogs of “translators and gateways” will be used (although not named that, too “EDI-ish”.) TANSTAAFL

30. So in addition to “EDI experts and specialized translation software” you’ll also need “XML experts and specialized translation software”. A significantly different technology with non-trivial learning curve. XML by itself is pretty simple, but things like “XSLT”, “XML Namespaces”, and “XML Schema” are non-trivial. But XML and ancillary technologies will fast become a fundamental universal data-processing skill, rather than an esoteric specialized skill like EDI. TANSTAAFL

31. And for awhile you will still have to interface between an XML “translator” and the back-end systems, just as with EDI. Bolting XML on the front will not change your existing back-end. XML helps at “lower layers” of the protocol stack, not at “higher layers”. TANSTAAFL Back-end integration will still be the major challenge!

32. However, your new XML environment will still be significantly “faster, cheaper, better” for the tasks it is given (once you’re over the learning curve!) and will increasingly make your business more competitive. More applications will be able to speak XML natively “out of the box”, especially as standards solidify, thus further improving XML’s cost/benefit ratio. “Plug-and-play” standards (e.g., RosettaNet) will have big payback if they in fact meet business needs as planned. So Why Bother?

33. EDI will stay relatively undisturbed for quite awhile. EDI does what it was designed to do and does it reliably. No need to disturb existing huge investment in technology, custom-developed software (“maps”), and staff expertise. B2B via XML will start penetrating areas that EDI has not touched due to EDI cost/benefit ratio. Large enterprises will be compelled by the need to compete in “Internet time” and to achieve new functionality. SME’s will be able to play cost-effectively in B2B as turn-key solutions arise (more likely/doable in XML). Whither EDI?

34. Eventually B2B via XML will start encroaching on EDI. But only after XML is much better established. XML cost factors, time-to-market factors, and functionality will gradually dictate “XML” rather than “EDI” for new/updated TP relationships in traditional EDI roles. An evolution, rather than a revolution. And much of EDI’s sophisticated business semantics may be merely transferred into the XML world. Whither EDI? XML - It’s just like EDI, only different.

35. What about EDI professionals? Again “it’s just like EDI, only different.” It’s “faster, cheaper, better” only at the lower techie levels. It’s a very natural thing to have the EDI group absorb “B2B via XML” along with existing EDI. “Just” ramp up on XML-specific skills and all other skills (business knowledge, analytical skills, project management, ability to interact with business folk and implement what they need) still apply as before. Whither EDI? Is EDI dead? To paraphrase Mark Twain: Rumors of my death have been greatly exaggerated!

36. Thank you