1. The Universal Business Language: An Excursus
Open 0pt65 spreadsheet!
Open 0pt65 XSD files in XML Spy!
Eve Maler
Sun Microsystems

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 one of its major subcommittees
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

3. Overview 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
Summary

4. Promises, promises

5. The promise of XML for e-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 realistic e-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
A joint 18-month effort, concluding in May 2001, 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 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

15. The UBL problem space

16. 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

17. 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, grind information
These differences need to be accommodated without sacrificing interoperability

18. UBL proposes to meet all these requirements

19. Where UBL can fit into existing XML B2B
Chemical
Mfr C
C’s industry
partners
CIDX
Hospital B
B’s industry
HL7
Electronics
Mfr A
A’s industry
RosettaNet

20. Making UBL happen

21. 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 is the chair and main founder

22. Some UBL participants 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

23. 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

24. 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

25. Formal liaisons so far ACORD (insurance) ARTS (retail sales)
e.centre (UK EAN.UCC)
EIDX (electronics)
HL7 (healthcare)
NACS (convenience stores)
RosettaNet (IT)
SWIFT (banking)
VCA (optical supplies)
XBRL (accounting)
ASC X12 (EDI)
UN/CEFACT (EDI)

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

27. Planned deliverables Phase 1: 2002 The UBL Library Schema design rules
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

28. Basic UBL Documents Order Order Response (simple)
Order Response (complex)
Order Change
Despatch Advice (shipping notice)
Receipt Advice
Invoice

29. 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 and printing UBL documents
Generating EDI-compliant instances
A secondary deliverable will be Core Components feedback

30. Design principles 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) …

31. ebXML Core Components

32. 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

33. A primer

34. 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

35. 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
Example dictionary name: Car.Colour.Code

36. 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

37. 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

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

39. The UBL modeling methodology

40. The approach

41. The inputs Documents/expertise from: xCBL 3.0 ebXML CCs
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

42. 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

43. The formalism
A spreadsheet with carefully designed columns

44. The back end

45. Samples
Schema

46. Designing the UBL schemas

47. How the design rules fit into schema creation

48. 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

49. The choice of schema language
We chose W3C XML Schema (XSD)
The other seriously considered choices were RELAX NG and Schematron
Main positives:
Traction in the industry
Tools availability
Main concerns:
Interoperability
Lack of support for Boolean operations
We have not foreclosed on generating other schema versions
But they would be non-normative

50. A taste of the naming rules
Dictionary entry names are fully qualified with object class names
But using these full names would result in hundreds of extra elements
We get reusability by allowing properties (elements) to “inherit” parent object classes (types), XPath-style
Delivery schedule IDs and order IDs could both be called <ID>
Each would be identifiable by means of //Order/ID and //DeliverySchedule/ID respectively

51. Schema modularity

52. Embedded documentation
Datatypes are annotated with UBL-related metadata
XHTML Basic is used in a conventional way to indicate the fields
<xsd:documentation> <xhtml:div class=“Object_Class"> <xhtml:p>Delivery</xhtml:p> </xhtml:div> <xhtml:div class=“Property_Term"> <xhtml:p>Schedule</xhtml:p> </xhtml:div> <xsd:documentation>

53. Encoding code lists
UBL will seek to import external datatype definitions in a conventional XSD form
Helping external organizations to create rigorous schemas
Defining a unique UBL element for each kind of code
We hope to promote a global code list marketplace with this idea
<CountryIdentificationCode>
<ISO3166CountryCode
xsi:type=“iso3166:CodeType”> BE
</ISO3166CountryCode>
</CountryIdentificationCode>

54. Contextualizing UBL

55. Context drivers The ebXML work identified eight top context drivers:
Business process
Industry
Product classification
Geopolitical region
Primary and supporting business roles
System capabilities
Official constraints
For example, “selling nuclear cereal to Finland” will have specific values along these axes
This set probably needs to be extensible

56. The “eight-space”
UBL defines BIEs, not CCs – they have a bit of real context in them
Typically just the business process
Everything else should ideally be “zeroed out”
A set of eight values identifies a unique business context
A trading community can associate their schema customizations with it

57. Phase 1 – context disclosure
Customizers will be expected to:
Handcraft an XSD derivation, adhering to XSD extension and restriction rules
Provide context driver metadata, adhering to UBL context derivation rules
A context hierarchy will mirror the XSD type hierarchy

58. Phase 2 – machine application of context
Customizers will be able to describe the desired schema changes in an abstract, “recombinant” way
These context rules will be applied by an engine to input schemas to get contextualized schemas
A subtle and difficult problem!

59. UBL status

60. Completed work The procurement document types are well along
The payment document types will be next
The common aggregate types (reusable BIEs) grow with analysis of every document
The common leaf types (CCTs) are perfunctory right now
The NDR SC intends to put itself out of work by the end of 2002

61. Meeting schedule The UBL TC meets only F2F
ballots are allowed by our rules
The larger SCs meet frequently by phone and do some work by
Library Content (LC) and Naming and Design Rules (NDR) are the hot areas right now
If you’re interested in joining, let me know
You must be an organizational or individual OASIS member
Individual membership is US$250/year

62. Resources

63. Where to find more information
OASIS UBL TC
White papers, presentations, and specifications are available
All mailing list archives are open to public view
ebXML
Core Components

64. How to comment The UBL comment list is open to all
Archive: lists.oasis-open.org/archives/ubl-comment
Signup: lists.oasis-open.org/ob/adm.pl
The Library Content and NDR SCs have spreadsheet forms for providing feedback

65. Summary

66. I hope you feel UBL has what it takes to be successful
User-driven, with deep partnership resources to call on
Focused on global requirements, with a commitment to true horizontal trade
A transparent standards process
Reuse of existing standards
A modularized structure based on a crucial B2B data dictionary
Dedicated to interoperability, even in customized form

67. Thanks! Questions?