The Universal Business Language: An Excursus

1
The UniversalBusiness LanguageAn Excursus

• Eve Maler
• Sun Microsystems

2
A little about me

• My specialties are
• XML information modeling
• Standards development and facilitation
• Im 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 fore-business?

• Plug n play electronic commerce
• Spontaneous trade
• No custom programming
• Ubiquity on the Internet
• Dirt-cheap tools
• Complete platform independence

6
Unfortunately, its not that simple

• Its 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 doesnt 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-progres
  s
• 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

• Its 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
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
UBLs 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
• Dont 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
• 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
• Todays 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
  elements 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
• Its aggregate because its 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)

• XSDs OO-like approach can neatly be mapped to
  ISO 11179 object classes and properties

39
The UBL modeling methodology
40
The approach
41
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 theres no match, this will be fed back to
  the CC project

42
The modeling steps

1. Working from an xCBL document type, analyze its
   constituent constructs to identify BBIEs and
   ABIEs
2. Establish each BIEs dictionary name, UBL name,
   definition, and business context
3. Establish its cardinality/optionality within its
   object class
4. Identify missing BIEs
5. Identify which BIEs are reusable
6. 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 ltIDgt
• 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

• ltxsddocumentationgt ltxhtmldiv
  classObject_Class"gt ltxhtmlpgtDeliverylt/xh
  tmlpgt lt/xhtmldivgt ltxhtmldiv
  classProperty_Term"gt ltxhtmlpgtSchedulelt/x
  htmlpgt lt/xhtmldivgt . . .ltxsddocumentatio
  ngt

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

• ltCountryIdentificationCodegt
• ltISO3166CountryCode
• xsitypeiso3166CodeTypegt
• BE
• lt/ISO3166CountryCodegt
• lt/CountryIdentificationCodegt

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
• Email ballots are allowed by our rules
• The larger SCs meet frequently by phone and do
  some work by email
• Library Content (LC) and Naming and Design Rules
  (NDR) are the hot areas right now
• If youre interested in joining, let me know
• You must be an organizational or individual OASIS
  member
• Individual membership is US250/year

62
Resources
63
Where to find more information

• OASIS UBL TC
• www.oasis-open.org/committees/ubl/
• www.oasis-open.org/committees/ubl/lcsc/
• www.oasis-open.org/committees/ubl/ndrsc/
• www.oasis-open.org/committees/ubl/cmsc/
• White papers, presentations, and specifications
  are available
• All mailing list archives are open to public view
• ebXML
• www.ebxml.org
• Core Components
• www.ebtwg.org

64
How to comment

• The UBL comment list is open to all
• Archivelists.oasis-open.org/archives/ubl-comment
  
• Signuplists.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?

• eve.maler_at_sun.com