1 / 111

XML for Internet Markets and Trading Communities Dr. Robert J. Glushko Document Engineering Commerce One, Inc .

NACHA Financial EC Council March 29, 2000. XML for Internet Markets and Trading Communities Dr. Robert J. Glushko Document Engineering Commerce One, Inc . About the Speaker.

paul
Download Presentation

XML for Internet Markets and Trading Communities Dr. Robert J. Glushko Document Engineering Commerce One, Inc .

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NACHA Financial EC Council March 29, 2000 • XML for Internet Markets and Trading Communities • Dr. Robert J. Glushko • Document Engineering • Commerce One, Inc.

  2. About the Speaker • Dr. Robert J. Glushko is Director, Document Engineering at Commerce One. He has over twenty years of R&D, consulting, and entrepreneurial experience in online publishing, Internet commerce, SGML and XML. He joined Commerce One in January 1999 when it acquired Veo Systems, which he co-founded in 1997 and where his last position was Director, Information Engineering. Prior to Veo Systems, Glushko was the Chief Scientist and Vice President of Passage Systems, a consulting and systems integration firm specializing in SGML-based publishing (which he co-founded in 1992). He has also worked at AT&T Bell Laboratories and the Software Engineering Institute of Carnegie-Mellon University. He has an undergraduate degree from Stanford, a MS (Software Engineering) from the Wang Institute, and a PhD (cognitive psychology) from UC San Diego.

  3. About Commerce One • Company • Founded 1996, acquired Veo Systems in 1/99, IPO 7/99 (CMRC) • Products • Complete “Commerce Chain” Solution for Suppliers, Buyers, Market Makers & Market Operators • Provider of “portal services” for a “Global Trading Web” • Commitment to Open and Interoperable XML • XML end-to-end in products and services • Aggressive participation in standards activities

  4. The 1-Minute Version • XML is the key foundation technology for the Internet and the “web for computers” instead of just the “web for eyes” • Interoperability and scalability to create new B2B models like exchanges and trading communities depend on XML • Traditional EDI can help XML achieve these goals

  5. Topics • Mini-Tutorial on XML • Why Electronic Commerce Needs XML: The Integration Challenge • The Transition from EDI to XML • XML Standards and Industry Initiatives for “Commerce Languages” • XML Initiatives for Interoperability among Commerce Languages • The Vision of “Plug and Play Commerce” and the Global Trading Web

  6. Mini-Tutorial on XML

  7. The XML Revolution • The Web was created to publish information for people • “eyes-only” was dominant design perspective • hard to search • hard to automate processing • The Web is using XML to become a platform for information exchange between computers (and people) • Overcomes HTML’s inherent limitations • Enables the new business models of the network economy

  8. “Untangling the Web” 25 April 1998 .."But the biggest role that XML is expected to play is in integrating the way that existing paper documents -- invoices, loan applications, contracts, insurance claims, you name it are exchanged between organizations around the world. Imagine what the world would be like if one company's computer system could automatically read any other organization's documents - and make complete sense of them? This is the goal that the technique known as EDI has struggled, unsuccessfully, to achieve for years. Though efforts have barely begun, there is a chance that XML could actually make that happen. If it did, business on the Web could run riot."

  9. Laptop Computer Catalog Entry As Seen “By Eye” on Today’s Web Laptop Computer IBM Thinkpad 600E 400 MHz 64 Mb 8 Gb 4.1 pounds $3200

  10. Laptop Computer in HTML <TITLE>Laptop Computer</TITLE> <BODY> <UL> <LI>IBM Thinkpad 600E <LI>400 MHz <LI>64 Mb <LI>8 Gb <LI>4.1 pounds <LI>$3200 </UL></BODY>

  11. Airline Schedule Entry As Seen “By Eye” Airline Schedule Flight Information United Airlines #200 San Francisco 11:30 Honolulu 2:30 $368.50

  12. HTML Airline Schedule <Title>Airline Schedule</Title> <Body> <H2>Flight Information</H2> <H3>United Airlines #200</H3> <UL><LI>San Francisco <LI>11:30 <LI>Honolulu <LI>2:30 <LI>$368.50 </UL></Body>

  13. HTML’s Limitations for Commerce • HTML is too format-oriented to describe products, services, participants, terms & conditions, etc., in a computer-processable form • HTML was designed as a simple markup language • simple structures: headings, lists, links • strong emphasis on formatting • weak for encoding content

  14. Markup is “Information Intelligence” • How much you can do with information depends on the extent and explicitness of its markup • Markup transforms a flat stream of text into a set of objects or elements that can be manipulated by other applications • HTML markup is “rich” or “smart” compared with RTF, which is rich compared with ASCII • HTML markup is “poor” or “dumb” compared with a content-oriented data model, such as the markup implied when information is in a database

  15. My Info Can Beat up Your Info • Better to make information “smart” and “self-aware” than to bury the intelligence into a custom processing application • “Dumb” data programs are always more brittle • “Smart” data can be used by multiple applications

  16. XML and Information “IQ” Content/structure-based text objects: XML, SGML, databases Formatted electronic text: HTML, word processing files Easier to translate to more “processability” / reusability Unstructured electronic text: ASCII Printed text

  17. XML -- Extensible Markup Language • a “Webified” simplification of SGML, the Standard Generalized Markup Language, widely used in “high-end” or “database” publishing to separate logical structure from presentation • instead of a fixed set of format-oriented tags like HTML, XML allows you to create whatever set of tags are needed for your type of information • this makes any XML instance “self-describing” and easily understood by computers and people • XML-encoded information is smart enough to support new classes of Web applications

  18. Customer Profiles Vendor Profiles Catalogs Datasheets Price Lists Purchase Orders Invoices Inventory Reports Bill of Materials Payments Deposits Credit Reports Bank Statements Directories Transportation Schedules Receipts many many more... XML’s Big Idea: Document Types

  19. Document Types and DTDs • “Document type” captures the distinctions between documents that make a difference • The Document Type Definition or DTD defines: • the class of documents that shares a common information model • permissible elements and attributes, their contents, the order in which they occur • The DTD is the “content model” or “document schema” or “document grammar” that makes an instance “self-describing” and turns document collections into databases

  20. DTDs, Parsers, and Validation • From any DTD an XML parser can be generated that: • reads a document instance (the XML data stream) • identifies the markup in it • creates a “parse tree” or “event stream” in which the structured message is arranged to be passed off to applications • The parser can also test the XML document for conformance with the rules of the DTD • A document instance that follows the rules of the DTD is “valid”

  21. Laptop Computer in XML <COMPUTER TYPE=“Laptop”> <MANUFACTURER>IBM</MANUFACTURER> <LINE>Thinkpad</LINE> <MODEL>600E</MODEL> <SPECIFICATIONS> <SPEED UNIT=“MHz”>400</SPEED> <MEMORY UNIT=“MB”>64</MEMORY> <DISK UNIT=“GB”>8</DISK> <WEIGHT UNIT=“POUND”>4.1 </WEIGHT> <PRICE CURRENCY=“USD”>3200</PRICE> </SPECIFICATIONS> </COMPUTER>

  22. Smarter Processing Enabled by XML • <COMPUTER> and <SPECIFICATIONS> provide logical containers for extracting and manipulating product information as a unit • Sort by <MANUFACTURER>, <SPEED>, <WEIGHT>, <PRICE>, etc. • Explicit identification of each part enables its automated processing • Convert <PRICE> from “USD” to Euro, Yen, etc.

  23. Airline Schedule in XML <TransportSchedule Type=“Airline”> <Segment Id=“United Airlines #200”> <Origin>San Francisco</Origin> <DepartTime TZ=“PST”>11:30 </DepartTime> <Destination>Honolulu</Destination> <ArriveTime TZ=“HST”> 2:30 </ArriveTime> <Price Currency=“USD”>368.50</Price> </Segment> </TransportSchedule>

  24. Example: Model for Transport Using the same model for all scheduled transportation services: <TransportSchedule Type=“Airline”> <TransportSchedule Type=“Train”> <TransportSchedule Type=“Ferry”> An application could create itineraries that involve more than one service by matching on locations and times

  25. Shared Semantics for Time and Location Shared semantics for location and time in related models that need them enables richer “commerce networks” of services: <TransportSchedule Type=“Airline”> … <Destination>Honolulu</Destination> <Accommodation Type=“Hotel”>... <Destination>Honolulu</Destination> <Event Type=“Concert”>… <Destination>Honolulu</Destination>

  26. XML as Technology Platform .. exchange data in an application and vendor neutral format XML WEB EDI CORBA / COM Document based API based

  27. Why Electronic Commerce Needs XML: The Integration Challenge

  28. Traditional Business Models and Integration Requirements • Traditional models for electronic business are based on long-term, point-to-point, and tightly coupled relationships • EDI is used here because high integration costs can be recovered over time • Partners are more willing to invest in compatible IT infrastructure at each end or in middleware that creates a distributed application

  29. Supply Chain Customers Enterprise Indirect Procurement Traditional Integration Challenge

  30. Internet Business Models and Integration Requirements • Internet enables new models for marketplaces, trading communities, outsourcing, open sourcing, buying consortia and “virtual enterprises” that are fundamentally different

  31. Assembly Outsourcing Distribution Supply Chain Customers Enterprise Indirect Procurement Markets Procurement Outsourcing The Internet Integration Challenge: Networks of Commerce Communities

  32. Internet Business Models andIntegration Requirements • Relationships are experimental and evolving and have shorter lifetimes overall • Both initial integration cost and incremental cost to evolve must be low • Point-to-point coupling approaches won’t support “describe once, {sell,buy} anywhere” goals • Global scalability puts a premium on being able to accommodate variation, and to describe services and business entities with metadata to accommodate dynamic trading

  33. Networked Trading Communities: New Challenges • Paper-based import/export and regulatory requirements • Flexible roles in complex processes (Transport: the buyer may be the shipper, the seller may be the shipper, or it may be a 3rd-party forwarder, and this changes for each leg of the journey!) • Descriptions of goods must be flexible (customs) and localized (ordering, payments, etc.) • Trading conventions are explicit - not understood across regional boundaries

  34. XML is part of the Solution • XML has the potential to enable a standards-conforming, open and extensible architecture for electronic commerce • XML standards could enable ubiquitous connectivity and interoperability and create the network effects of “describe once, {sell,buy} anywhere” and reusable marketplace services

  35. But EDI is part of the solution, too... • We must preserve the business processes and expertise embedded in EDI • The transition from EDI to XML must overcome some challenges and must combine EDI expertise with cutting-edgeXML and repository technology

  36. The Transition From EDI to XML

  37. The Transition from EDI to XML • Business Challenges • Technical Challenges from the Perspective of the “XMLers” • Technical Challenges from the Perspective of the “EDIers”

  38. EDI Benefit of Using XML Syntax XML Perspective of Company Creating a New Internet Marketplace Implementation & Maintenance Cost Time

  39. EDI XML Cost of creating XML document types and mapping to/ from EDI Perspective of EDI-enabled Supplier Implementation & Maintenance Cost Time

  40. XML/EDI • Numerous initiatives underway to translate EDI concepts and specifications to XML • Some have modest incremental goal of translating X12 or EDIFACT data element definitions to XML syntax • Others envision a radical re-thinking of EDI

  41. XML/EDI Efforts • Associated With “Official” Standards Organizations • X12C (and I, H, N...) • UN/EDIFACT • TMWG • SIMPL-EDI (e-Centre, UK) • CEN/ISSS

  42. XML/EDI Efforts • Industry Initiatives • OBI • RosettaNet • Commerce Net eCo Framework

  43. XML/EDI Efforts • Other • Common Business Library (Commerce One) • “UN XML” (EDI-TIE) • XML/EDI Group • Frankfurt University

  44. Technical Challenges for the “XMLers” • Standards process takes too long • EDI subsets not standard and not formally defined • No formal starting points -> No standard transformation approaches • EDI message architecture mixes content, addressing, and business process choreography • Syntactic constructs in EDI messages leads to “anonymous” constructs in XML

  45. Technical Challenges for the “EDIers” • Anarchy in XML “Standards” -- pick any three letters and it’s an acronym for an XML initiative • DTDs, with their roots in structural modeling for publishing, lack sufficient modeling power to model constraints needed in EDI • But which XML Schema language to use? • Different architectures for separating content, addressing, and business process choreography

  46. XML Schema Languages • XML’s publishing roots give it structural modeling capabilities in DTDs but it encodes content as “just text” and can’t express structural relationships between document types • W3C XML Schema effort underway to allow models with strong datatyping and inheritance

  47. Goals for an XML Schema Language • Use XML grammar, tools, and technology more ubiquitously • Replace DTDs -- DTDs are strange syntactically, so that XML tools that need information about DTDs don’t need to know how to read them (as long as they can parse an instance)

  48. Goals for an XML Schema Language • Make XML more friendly to programmers • more like database schemas, programming constructs (e.g. Java classes) • enable easier reuse of XML and associated code

  49. Goals for an XML Schema Language • Specify information that can’t be represented in DTDs (prohibited in “vanilla” XML because of SGML compatibility) • datatypes, not just strings • more constraints • inheritance • documentation as 1st class information (instead of comments, which can’t be programmatically processed)

  50. XML Schemas in Electronic Commerce • Essential to treat Dates, Monetary amounts, etc. as datatypes to enable validation • Schema inheritance and extension mechanisms allow custom versions of same document to co-exist • software can distinguish extensions from standard document • software can decide whether or not extensions can be safely ignored

More Related