Business Vocabularies in XML (or, Toward a Universal Business Language)

1. Eve Maler, Sun Microsystems Business Vocabularies in XML(or, Toward a Universal Business Language)

2. A little about me • My specialties are: • XML information modeling • Standards development and facilitation • I’m on the OASIS UBL Technical Committee and I chair a major subcommittee • I fill several key roles on the SAML standard effort • In previous lives I helped develop DocBook, XML itself, XLink, Pipeline, and more • And wrote a book on SGML DTD design methodology • Now it’s your turn…

3. Agenda • Promises, promises • EDI and ebXML • The UBL problem space • Making UBL happen • ebXML Core Components • The UBL modeling methodology • Designing the UBL schemas • Contextualizing UBL • UBL status • Resources

4. Promises, promises

5. The promise of XML fore-business? • Plug ‘n’ play electronic commerce • Spontaneous trade • No custom programming • Ubiquity on the Internet • Dirt-cheap tools • Complete platform independence

6. Unfortunately, it’s not that simple • It’s very difficult, and maybe not even desirable, to take the humans out of business • Building trust relationships • Exception handling • XML is just a metalanguage • Tag soup doesn’t give you interoperability • Seamless communication requires shared meaning • Shared meaning requires semantic standardization across whole industries • This is where UBL comes in

7. The Universal Business Language • An XML-based business language standard-in-progress • Leverages existing EDI and XML B2B • Applicable across all industry sectors and domains of electronic trade • Actually modular, reusable, and extensible • Non-proprietary and committed to freedom from royalties • Intended to become a legal standard for international trade

8. UBL offers some realistice-business promises • Genuine advantages over EDI and proprietary/vertical XML B2B: • Lower cost of integration, both among and within enterprises • Lower cost of commercial software • Easier learning curve • Lower cost of entry • Quicker adoption by small and medium-size enterprises (SMEs) • Standardized training • Universally available pool of skilled workers

9. EDI and ebXML

10. The EDI stack

11. Some EDI pressure points • It’s hard to get in the game • Private networks are expensive • You need to do extensive point-to-point negotiation • The interchange pipe is large, with infinite possible subsets • You use a “soft” mechanism for adapting to special business contexts

12. The ebXML initiative • It was a joint 18-month effort of: • OASIS (Organization for the Advancement of Structured Information Standards) • UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) • Over 1000 international participants • The vision: a global electronic marketplace • Enterprises of any size, anywhere, can: • Find each other electronically • Conduct business by exchanging XML messages • ebXML work continues in several venues

13. The ebXML stack

14. ebXML modules for infrastructure • ebXML Message Service (ebMS) • Secure, reliable messaging built on SOAP with Attachments • Has bindings to HTTP and SMTP • Business Process Schema Specification (BPSS) • Business process descriptions in XML • Collaboration Protocol Profile/Agreement (CPP/CPA) • Description of business partners’ technical abilities and agreements about business collaboration • Registry/Repository (Reg/Rep) • Submission, query, and retrieval of e-business artifacts, with rich metadata

15. ebXML work on payloads • Core Components • Syntax-neutral catalog of idealized, context-free business semantics • Able to be mapped to EDI, XML, or other syntaxes • More on this later • Context Methodology • Part of Core Components work • Initial cut at methods for applying business context to Core Components and doing assembly

16. An ebXML usage scenario

17. ebXML status • The infrastructure specifications are all maturing; most are past V2.0 • The Reg/Rep spec has been approved as an OASIS Standard • The payload specs are in active development • Conformance tests are being developed • Industry groups are endorsing ebXML • OTA, AIAG, RosettaNet, and more • Products, open source implementations, interop events, and pilots are happening • Both “sanction” and “traction” are well on their way

18. The UBL problem space

19. Some basic requirements • Semantic clarity through a binding from Core Components to a syntax • Choosing XML as that syntax! • Royalty-free IPR • Usable “on the cheap” • No ties to particular back-end implementations • Urgency

20. The requirement for context • “Standard” business components need to be different in different business contexts • Addresses differ in Japan vs. the U.S. • Addresses in the auto industry differ from those for other industries • Invoice items for shoes need size information; for coffee, they need grind information • These differences need to be accommodated without sacrificing interoperability

21. UBL proposes to meet all these requirements

22. Making UBL happen

23. The standards venue • UBL is being developed in an OASIS Technical Committee • Like most of the follow-on ebXML infrastructure projects • (The follow-on Core Components and Business Process projects are in UN/CEFACT) • OASIS offers: • An objective process • Openness of its work to public view in real time • Easy and inexpensive opportunities to join • Jon Bosak (F.O.X.) is the chair and main founder

24. APACS Boeing Commerce One Danish Bankers Association France Telecom General Electric Government of Hongkong Government of Korea HP Intuit KPMG LMI Northrup Grumman Oracle PricewaterhouseCoopers SAP SeeBeyond Sterling Commerce Sun Microsystems UK Cabinet Office United Parcel Service U.S. GSA U.S. Navy Visa International Some UBL participants

25. UBL’s relationship with ebXML • UBL is not actually an “ebXML deliverable” • UBL mandates no particular messaging framework • But we hope the combination will enable the “B2B web” • HTTP + HTML = web publishing • ebXML + UBL = web commerce

26. Development strategies • Start with the low-hanging fruit • The 20% of documents and business objects actually used by 80% of electronic business partners • Defer the rocket science to later phases • Produce useful, concrete outputs ASAP • Don’t start with a blank slate • We are working from xCBL 3.0 • But with no expectations of backwards compatibility • Take advantage of domain expertise • Get XML experts and business experts together and form liaisons

27. Formal liaisons so far • Industry groups • ACORD (insurance industry) • ARTS (retail sales) • EIDX (electronics industry) • RosettaNet (IT industry) • XBRL (accounting professionals) • De jure standards organizations • ANSI X12 (EDI) • UN/CEFACT (EDI)

28. UBL subcommittee organization • Modeling and content • Library Content • Context Drivers • (future domain-specific) • XML representation and mechanisms • Naming and Design Rules • Context Methodology • Tools and Techniques • Administrative functions • Marketing • Liaison • Subcommittee chairs

29. Phase 1: 2002 The UBL Library Reusable building blocks and standard document types Schema design rules How to represent UBL in XML/XSD How external modules can best work with UBL Simple context methodology How to add context-based extensions to UBL Phase 2: 2003 Full-blown context methodology How to describe your extensions in “recombinant” fashion Planned deliverables

30. Common building blocks “Leaf” and aggregate Procurement Purchase order, PO response, PO change Materials management Advance ship notice, planning schedule, goods receipt Payment Commercial invoice, remittance advice Transport/logistics Consignment status request and report, bill of lading Catalogs Price catalog, product catalog Statistical reports Accounting report Business document scope

31. More about the UBL Library deliverables • The normative W3C XML Schema (XSD) modules • Documentation • Potentially several non-normative forms: • UML • ASN.1 • Other schema representations • Modified XSD • Potentially stylesheets for: • Viewing UBL documents • Generating EDI-compliant instances • A secondary deliverable will be Core Components feedback

32. Straightforward Internet use “Various and sundry” tools Legibility Simplicity 80/20 rule Component reuse Provide one way to encode information Customization and maintenance Context sensitivity Prescriptiveness, tempered Content orientation XML technology Namespace dependency caution Legacy format non-goal xCBL subset non-goal (Schema generation) … … Design principles

33. ebXML Core Components

34. Core Components status • The Core Components Technical Specification, Part 1, is at V1.8 • Known as CCTS • Some features are still a matter of hot debate • Additional Core Components Supplementary Documents work is ongoing • Known as CCSD • Today’s tutorial reflects the current CCTS specification and not the newer or more controversial areas

35. A primer

36. More on Core Component Types • CCTs are conceptually similar to the notion of built-in datatypes in XML • The spec offers a closed set of them • But this comparison says nothing about their schema representation, such as simple vs. complex types • Current CCTs: • Amount – Measure • Code – Numeric • DateTime – Picture • Graphic – Quantity • Identifier – Text • Indicator

37. Mapping to data elements • CCTS constructs follow ISO 11179 • Semantic clarity of data elements (CCs and BIEs) is achieved through careful naming and definition in a dictionary • A CC or BIE gets a tripartite dictionary name • The object class to which the data element belongs • A term reflecting its function as a property or distinguishing characteristic of the object class • A representation term (RT) defining the data element’s valid values • RTs are closely related to CCTs • Current RTs are Amount, Code, Date, DateTime, Graphic, Identifier, Indicator, Measure, Name, Percent, Picture, Quantity, Rate, Text, Time, and Value – plus Details • Example dictionary name: Car.Colour.Code

38. More on the notion of business context • An example of an ACC might be “address” • It’s aggregate because it’s a collection of other CCs • As a CC, it strives to be semantically unique and useful • An example of an ABIE might be “buyer address” • As a BIE, it strives to identify the business circumstance in which the CC is used • The dictionary name would be Buyer.Address.Details

39. Mapping the CC world to XML and XSD (1 of 2) • XSD has an indirect cascade of types and elements • With attributes working pretty much the way elements do

40. Mapping the CC world to XML and XSD (2 of 2) • XSD’s OO-like approach can neatly be mapped to ISO 11179 object classes and properties

41. The UBL modeling methodology

42. The approach

43. The inputs • Documents/expertise from: • The members of the Library Content SC • Organizations with a liaison to the UBL TC • Feedback from the general public • xCBL 3.0 • A working XML business vocabulary for several years • Has lots of EDI knowledge baked into it • ebXML CCs • Ultimately, as many UBL constructs as possible will be mapped to the final form of CCs • Where there’s no match, this will be fed back to the CC project

44. The modeling steps • Working from an xCBL document type, analyze its constituent constructs to identify BBIEs and ABIEs • Establish each BIE’s dictionary name, UBL name, definition, and business context • Establish its cardinality/optionality within its object class • Identify missing BIEs • Identify which BIEs are reusable • Assemble an appropriate UBL document type from the BIEs

45. The formalism • A spreadsheet with carefully designed columns

46. The back end

47. Samples • Schema • Instance

48. Designing the UBL schemas

49. How the design rules fit into schema creation

50. Some major design rules developed so far • The choice of normative schema language • Naming and construction of elements, attributes, and types (mostly done) • Modularity, namespaces, and versioning (partial) • Embedded schema documentation (draft) • Handling code lists