designing business documents with ublevents.oasis-open.org/home/sites/events.oasis-open.org... ·...

COMPOSING MEANINGFUL DOCUMENTS WITH UBL

Tim McGrathOpen Standards 2008: Composability within SOA Symposium

Date: 28 April – 1 MayLocation: Santa Clara Marriott

- an approach to design and customization of UBL to satisfy specific requirements UBL is establishing itself as the language of choice for a variety of electronic commerce applications. It is

particularly well suited for use in business web services and service oriented architectures. The use of UBL for such environments ensures that services remain meaningful and worthy in a variety of different compositions. Inevitably, these applications may require some refinement of the standard structures.

This presentation explains some of the design principles behind UBL and how both the standard components and the principles behind them can be adapted to suit the requirements of different business processes. We will explore a case study involving the Danish Government's OIOUBL and Service Oriented Infrastructure project.

Composing different services into a meaningful business process requires interoperability of the information contained in the documents exchanged. This tutorial will discuss the opportunities for utilizing the OASIS Universal Business Language (UBL) as the glue to bind these services together at a business data level.

This tutorial explains the design principles behind UBL and how it can be adapted to suit the requirements of different business processes. These composite applications will require some customization of the standard structures and the creation of new document types.

The objective is to enable participants to understand the issues involved in customizing UBL and how to develop specific implementations that suit the requirements of their context of use. The target audience is system analysts and developers responsible for the implementation of document interfaces.

Outline

• Background to Document Design• UBL Design• UBL Specification• Case Study Scenario• Designing Customizations• Specifying Customizations• Validating Customizations• Summary and Feedback

IntroductionsWho are we and why are we here?

Background to Document Design

What are Documents?

• For nearly three thousand years information has been organized in purposeful and self-contained packages.– We call them documents.

• Using documents for exchanging business information is an old idea.– The technology for encoding and exchanging documents has

profoundly changedbut – The concept of a document has remained surprisingly stable.

Using documents for exchanging business information is natural and intuitive.

<cac:TaxTotal> <cbc:TaxAmount currencyID=“SHEKEL">60.00</cbc:TaxAmount> <cac:TaxSubtotal> <cbc:TaxableAmount currencyID=“SHEKEL">100.00</cbc:TaxableAmount> <cbc:TaxAmount currencyID=“SHEKEL">14.00</cbc:TaxAmount> <cac:TaxCategory> <cac:TaxScheme> <cbc:ID>ASSYRIAN GOVERNOR TAX</cbc:ID> </cac:TaxScheme> </cac:TaxCategory> </cac:TaxSubtotal></cac:TaxTotal>

Design Principles

XML Document

How Documents Work

• Documents are self-contained collections of information.– Interfaces for people.– Interfaces to business processes.

• To be meaningful documents must be defined using a common language.– Not for information content but – For describing the meaning (semantics) of the information

content.

• The Universal Business Language is a semantic document description language.

Document Exchange

• A document exchange consists of both processes and the documents (information) they produce and consume.

• By understanding the processes– we learn what kinds of information is needed.

• By understanding the document – we learn what kinds of processes are possible.

Interoperability

• A basic requirement for two businesses to conduct business is that their business systems interoperate.

• Easy to express but hard to achieve.• Variations in strategies, technology platforms, legacy

applications, business processes, and terminology.• Interoperability doesn’t require that two systems be

identical.– Just they have common understanding of the meanings of

things (semantics)

UBL Design

UBL Design ebXML Core Components

ebXML CCTS

• ebXML Core Components Technical Specification:– ISO 15000-5.– UN/CEFACT

• How to describe core components of business documents in a syntax independent manner.

• UBL is the first set of integrated XML document specifications based on CCTS.– UN/CEFACT recognizes UBL as appropriate first-generation

XML documents for eBusiness.

CCTS Principles

is definedin context

Core ComponentType (CCT)

Aggregate CoreComponent (BCC)

Basic CoreComponent (BCC)

Aggregate BusinessInformation Entity

(ABIE)

Basic BusinessInformation Entity

(BBIE)is of type

Core Business

Message/Document

These are implied

concepts

UBL publishes these

Business Information Entities

• Reusable building blocks for the exchange of information (“Core Components”) in a specific Business Context.

• Aggregate BIE– A collection of related pieces of business information that together convey

a distinct business meaning.

• Association BIE– Is associated to an Aggregate Business Information Entity,

which describes its structure. • Basic BIE

– A singular business characteristic of a specific aggregation.

Basic Business Information Entities

• A singular business characteristic in a specific business context.

• Individual pieces of information.

cd BIEs

«ABIE»An Address

# «BBIE» Street Name: Name [0..1]# «BBIE» City Name: Name [0..1]

AggregateBusiness Information Entities

• A collection of related pieces of business information. • A container of BBIEs and ASBIEs to other ABIEs.

cd BIEs

«ABIE»An Address

AssociationBusiness Information Entities

• Represents an ABIE in a specific business context.• An ABIE contained within another ABIE.

cd BIEs

«ABIE»An Address

«ABIE»A Country

# «BBIE» Identification Code: Code [0..1]# «BBIE» Name: Name [0..1]

UBL Design Naming Information Entities

• Meaningful Information Entity names. – promote a common understanding. – encourage reuse.

• May need different names in different modeling artifacts.– XML Tag may not be the modeling or the presentation name.

Choosing the Right Names

● Selecting meaningful terminology for names is a craft not a science.

• Think about spoken languages.• No two designers will choose the same terms.

• Levels of discipline:• Dictionaries.• Controlled vocabularies.• Formal ontologies.

• We need more information than just names.• We also need to understand the context of use.

Rules for Consistent Naming

• Names should be grammatically consistent.– Singular not plurals

• Names should not be ambiguous.– Is “Supplier’s ID” the same as “ID of Supplier”?

• Check names are not semantically misleading. – “Product Number” may not be a number, so “Product

Identifier” is better. • Qualify names to clarify the context of use.

– “Customer Party” is more meaningful than “Customer”.

ebXML Naming Rules

• ebXML Core Components naming rules are an application of ISO 11179.

• All Information Entities get a Dictionary Entry Name (DEN).

• Dictionary Entry Names are globally unique.• They are the ‘key’ or unique identifier for any

Information Entity.

Dictionary Entry Names

{qualifier} Object Class Term, “. ”, {qualifier} Property Term, “. ”, {qualifier} Representation Term

• Object Class Term– The object class to which it belongs.

• Property Term– Reflecting its function as a property or distinguishing characteristic

of the object class.• Representation Term

– How it is represented.

Examples of CCTS Names

– The name for ‘The currency in which the tax is collected and reported, expressed as a code’:

Tax Scheme. Currency Code. Code

Object Class Property Representation

ABIE BBIE Data Type

Qualified CCTS Names

– The name for ‘An indicator as to whether these totals are recognized as legal evidence for taxation purposes’:

Tax Total. Tax Evidence_ Indicator. Indicator

Object Class Property RepresentationQualifier

ABIE Data TypeBBIE

CCTS Truncation Rule

– The name for ‘Identifies the tax scheme’:

Tax Scheme. Identifier. Identifier

– Can be truncated to remove duplicate terms:

Tax Scheme. Identifier

UBL DesignRepresentation Terms

Amount

The version of the UN/ECE rec. 9 code list.Amount. Currency. Code List Version Identifier

The currency of the amount.Amount. Currency. Identifier

A number of monetary units specified in a currency where the unit of currency is explicit or implied.

Content

<cbc:TaxAmount currencyID="DKK">1262.50</cbc:TaxAmount>

Binary Object(Graphic, Picture, Sound, Video)

The filename of the binary object.Binary Object. Filename. Text

The Uniform Resource Identifier that identifies where the binary object is located.

Binary Object. Uniform Resource. Identifier

The character set of the binary object if the mime type is text.

Binary Object. Character Set. Code

Specifies the decoding algorithm of the binary object.

Binary Object. Encoding. Code

The mime type of the binary object.Binary Object. Mime. Code

The format of the binary content.Binary Object. Format. Text

A set of finite-length sequences of binary octets.Binary Object. Content

<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" encodingCode="Base64" characterSetCode="UTF-8">brIG0Ng53KHKaoOQNQYcpyFHKa9UhkgzjkPBTaFJDIBUasfdgartujjuoprrwer34578deewcwetyuuutyur643432THyB4KY5SYM5BZcpMkshU0UzJoLHSDEWFdreefssd///</cbc:EmbeddedDocumentBinaryObject>

The name of the agency that maintains the code list.

Code List. Agency Name. Text

An agency that maintains one or more code lists.

Code List. Agency. Identifier

The identification of a list of codes.Code List. Identifier

A character string (letters, figures or symbols) that for brevity and/or language independence may be used to represent or replace a definitive value or text of an attribute.

Code. Content

<cbc:ItemClassificationCode listID="UNSPSC" listVersionID="7.0401">43191501</cbc:ItemClassificationCode>

Code (contd.)

The Uniform Resource identifier that identifies where the code list scheme is located.

Code List Scheme. Uniform Resource. Identifier

The Uniform Resource Identifier that identifies where the code list is located.

Code List. Uniform Resource. Identifier

The identifier of the language used in the corresponding text string.

Language. Identifier

The textual equivalent of the code content.Code. Name. Text

The version of the code list.Code List. Version. Identifier

The name of a list of codes.Code List. Name. Text

Date Time(Date, Time)

The format of the date/time content.Date Time. Format. Text

The particular point in the progression of time.

Date Time. Content

<cbc:StartDate>2007-01-25</cbc:StartDate>

Identifier

The name of the identification scheme.Identification Scheme. Name. Text

The identification of the identification scheme.Identification Scheme. Identifier

A character string used to identify and distinguish uniquely, one instance of an object in an identification scheme from all other objects within the same scheme.

Identifier. Content

<cbc:ID schemeID=”GTIN">5712345780121</cbc:ID>

Identifier (contd.)

The Uniform Resource Identifier that identifies where the identification scheme is located.

Identification Scheme. Uniform Resource. Identifier

The Uniform Resource Identifier that identifies where the identification scheme data is located.

Identification Scheme Data. Uniform Resource. Identifier

The version of the identification scheme.Identification Scheme. Version. Identifier

The name of the agency that maintains the identification scheme.

Identification Scheme. Agency Name. Text

The identification of the agency that maintains the identification scheme.

Identification Scheme Agency. Identifier

Indicator

Whether the indicator is numeric, textual or binary.

Indicator. Format. Text

The value of the indicator.Indicator. Content

<cbc:ChargeIndicator>false</cbc:ChargeIndicator>

Measure

The version of the measure unit code list.

Measure Unit. Code List Version. Identifier

The type of unit of measure.Measure Unit. Code

The numeric value determined by measuring an object.

Measure. Content

<cbc:GrossWeightMeasure unitCode="KGS">21408.79</cbc:GrossWeightMeasure>

Numeric. Content Numeric information that is assigned or is determined by calculation, counting or sequencing.

Numeric(Value, Rate, Percent)

Whether the number is an integer, decimal, real number or percentage.

Numeric. Format. Text

<cbc:PackSizeNumeric>1</cbc:PackSizeNumeric>>

Quantity

The name of the agency which maintains the quantity unit code list.

Quantity Unit. Code List Agency Name. Text

The identification of the agency that maintains the quantity unit code list.

Quantity Unit. Code List Agency. Identifier

The quantity unit code list.Quantity Unit. Code List. Identifier

The unit of the quantity.Quantity. Unit. Code

A counted number of non-monetary units possibly including fractions.

Quantity. Content

<cbc:PackQuantity unitCode="EA">1</cbc:PackQuantity>

Text(Name)

The identification of the locale of the language.

Language. Locale. Identifier

A character string (I.e. a finite set of characters) generally in the form of words of a language.

Text. Content

<cbc:Description>Nokia Mobile telephone –Type ABC</cbc:Description>

Note: The Representation term “Text” is not part of the tag name (UBL naming rule)

UBL Design Codes and Identifiers

Sets of Codes

• A special set of possible values. • The code value refers to something else.• May be symbolic representations:

– Initialisms (“EU”), – Acronyms (“SARS”), – Apocopations (“Reefer”) or – Arbitrary abbreviations (“XML”).

• But maybe not...– Both ISO code “CNY” and “156” identify the Chinese Yuan

Renminbi.

Codes and Values

Types of packaging codes

Units of Measurement codes

Refers to

Identifiers

• Have meaning in their own right.– Don’t have to reference anything.

• May be a constrained set of values:– Set of Driver’s License numbers issued.

• May be symbolic representations (like codes).• Or (effectively) not…

• The values for identifying a phone number.

• We use codes as identifiers:– Digits in phone numbers are codes for regions.

• But not identifiers as codes:– What does your Driver’s License number refer to?

What are these?

ABCU123456789000ABCU123456789001

ABCUIJKL123456XYZ

NHKL7654321HPGL8877665

OCLU1234567And these?Shipping Container Numbers

Waybill Numbers

UBL Specification

Specifying Documents

• We need a range of metadata to support the explanation of meanings.– Names are not enough.

• We define these in models.

UBL SpecificationModels and Modeling

• A generalized, conceptual model. – “webs” or networks.– Domain Model, Enterprise Data Model.

• Not a model of one document…but,

• A model of Information Entities usable in all documents.– and databases, etc.

• Complexity depends on the number of the business rules.

Component Models

A Component Model

cd Major Entities

«ABIE»Common Library::Item

«ABIE»Shipment

«ABIE»Goods Item

«ABIE»Consignment

«ABIE»Transport Equipment

«ABIE»Transport Means

«ABIE»Common Library::Package

«ABIE»Shipment Stage

«ABIE»Transport Handling Unit

«ABIE»Procurement Library::Line Item

T RADE VIEW

T RANSPORT VIEW

«ABIE»Goods Item Container

0..* 0 ..*

transport view toequipm ent

transport view to package

trade view to package0..*0..1

trade view to i tem

transport view to i tem

UBL’s Common Components

UBL Specification Assembling Components

into Documents

Documents are Hierarchical

• Inverse tree structure.

• Can be represented in a 2D space.– That’s why markup languages need just <start> and

</end> tags.

• Nesting imposes meaning. – When “Contact” contains “Name” we know that the

name is that of the contact. – Parent (genealogy) gives contact of use.

Hierarchy not Network

cd Customer Party

«ABIE»Customer Party

# «BBIE» Customer Assigned Account ID: Identifier [0..1]# «BBIE» Supplier Assigned Account ID: Identifier [0..1]# «BBIE» Additional Account ID: Identifier [0..*]

«ABIE»Common Library::Party

# «BBIE» Mark Care Indicator: Indicator [0..1]# «BBIE» Mark Attention Indicator: Indicator [0..1]- «BBIE» Website URI: Identifier [0..1]- «BBIE» Logo Reference ID: Identifier [0..1]- «BBIE» End Point ID: Identifier [0..1]

«ABIE»Common Library::Contact

# «BBIE» ID: Identifier [0..1]# «BBIE» Name: Name [0..1]# «BBIE» Telephone: Text [0..1]# «BBIE» Telefax: Text [0..1]# «BBIE» Electronic Mail: Text [0..1]# «BBIE» Note: Text [0..1]

0..1+Buyer

0..1+Accounting

+Del ivery0..1

A Document Assembly Model

Another Document Assembly Model

Creating a Document Assembly

• Each type of document usually requires its own document assembly model.

• We create a document assembly model by:1. Choosing an “entry point” into the Document Component

Model.• The entry point is a structure that will form the root of the

document tree.

2. Following a pathway through the component model– guided by business rules for the document required.

• If an association is mandatory:– must follow the path– the associated ABIE must be in the document.

• If an association is optional:– may follow the path– the associated ABIE can be in the document if required by

business rules.

• Cardinality of associations controls the depth of the document hierarchy.

Assembling Associations

UBL Specification Assembly Patterns

Patterns for Document Assembly

• Document assembly models express business rules based on the context of use.

• Many assemblies share common structures. – There are patterns of assemblies. – a Book, a Contract, an Order.

• Good designers employ these patterns…

– Because processes will find their documents familiar.

The “Book” Assembly Pattern

cd Book Assembly Pattern

Text Book

Foreword Preface Introduction Chapter Appendix Bibliography Index

Section Exercise

0..1 0..1 1 1..* 0..1 0..1 0..1

0..* 0..*

Reusing Assembly Patterns

• Assembly patterns encourages the use of common libraries of components. – Reusing patterns from elsewhere in the model– Adopting patterns from outside

• The challenge is customizing these patterns to suit specific requirements.

04/04/08

Tim McGrathOpen Standards 2008: Composability within SOA Symposium

Date: 28 April – 1 MayLocation: Santa Clara Marriott

04/04/08

- an approach to design and customization of UBL to satisfy specific requirements UBL is establishing itself as the language of choice for a variety of electronic commerce applications. It is

particularly well suited for use in business web services and service oriented architectures. The use of UBL for such environments ensures that services remain meaningful and worthy in a variety of different compositions. Inevitably, these applications may require some refinement of the standard structures.

This presentation explains some of the design principles behind UBL and how both the standard components and the principles behind them can be adapted to suit the requirements of different business processes. We will explore a case study involving the Danish Government's OIOUBL and Service Oriented Infrastructure project.

Composing different services into a meaningful business process requires interoperability of the information contained in the documents exchanged. This tutorial will discuss the opportunities for utilizing the OASIS Universal Business Language (UBL) as the glue to bind these services together at a business data level.

This tutorial explains the design principles behind UBL and how it can be adapted to suit the requirements of different business processes. These composite applications will require some customization of the standard structures and the creation of new document types.

The objective is to enable participants to understand the issues involved in customizing UBL and how to develop specific implementations that suit the requirements of their context of use. The target audience is system analysts and developers responsible for the implementation of document interfaces.

04/04/08

Outline

• Background to Document Design• UBL Design• UBL Specification• Case Study Scenario• Designing Customizations• Specifying Customizations• Validating Customizations• Summary and Feedback

04/04/08

IntroductionsWho are we and why are we here?

04/04/08

Background to Document Design

04/04/08

What are Documents?

• For nearly three thousand years information has been organized in purposeful and self-contained packages.– We call them documents.

• Using documents for exchanging business information is an old idea.– The technology for encoding and exchanging documents has

profoundly changedbut – The concept of a document has remained surprisingly stable.

04/04/08

Using documents for exchanging business information is natural and intuitive.

8@ Port Community Systems 2007

Designing Business Documents with UBL

04/04/08

How Documents Work

• Documents are self-contained collections of information.– Interfaces for people.– Interfaces to business processes.

• To be meaningful documents must be defined using a common language.– Not for information content but – For describing the meaning (semantics) of the information

content.

• The Universal Business Language is a semantic document description language.

04/04/08

Document Exchange

• A document exchange consists of both processes and the documents (information) they produce and consume.

• By understanding the processes– we learn what kinds of information is needed.

• By understanding the document – we learn what kinds of processes are possible.

04/04/08

Interoperability

• A basic requirement for two businesses to conduct business is that their business systems interoperate.

• Easy to express but hard to achieve.• Variations in strategies, technology platforms, legacy

applications, business processes, and terminology.• Interoperability doesn’t require that two systems be

identical.– Just they have common understanding of the meanings of

things (semantics)

04/04/08

UBL Design

04/04/08

UBL Design ebXML Core Components

04/04/08

ebXML CCTS

• ebXML Core Components Technical Specification:– ISO 15000-5.– UN/CEFACT

• How to describe core components of business documents in a syntax independent manner.

• UBL is the first set of integrated XML document specifications based on CCTS.– UN/CEFACT recognizes UBL as appropriate first-generation

XML documents for eBusiness.

04/04/08

CCTS Principles

is definedin context

Core ComponentType (CCT)

Aggregate CoreComponent (BCC)

Basic CoreComponent (BCC)

Aggregate BusinessInformation Entity

(ABIE)

Basic BusinessInformation Entity

(BBIE)is of type

Core Business

Message/Document

These are implied

concepts

UBL publishes these

04/04/08

Business Information Entities

• Reusable building blocks for the exchange of information (“Core Components”) in a specific Business Context.

• Aggregate BIE– A collection of related pieces of business information that together convey

a distinct business meaning.

• Association BIE– Is associated to an Aggregate Business Information Entity,

which describes its structure. • Basic BIE

– A singular business characteristic of a specific aggregation.

04/04/08

Basic Business Information Entities

• A singular business characteristic in a specific business context.

• Individual pieces of information.

Design Principles

cd BIEs

«ABIE»An Address

04/04/08

AggregateBusiness Information Entities

• A collection of related pieces of business information. • A container of BBIEs and ASBIEs to other ABIEs.

Design Principles

cd BIEs

«ABIE»An Address

04/04/08

AssociationBusiness Information Entities

• Represents an ABIE in a specific business context.• An ABIE contained within another ABIE.

Design Principles

cd BIEs

«ABIE»An Address

«ABIE»A Country

# «BBIE» Identification Code: Code [0..1]# «BBIE» Name: Name [0..1]

04/04/08

UBL Design Naming Information Entities

04/04/08

• Meaningful Information Entity names. – promote a common understanding. – encourage reuse.

• May need different names in different modeling artifacts.– XML Tag may not be the modeling or the presentation name.

04/04/08

Rules for Consistent Naming

• Names should be grammatically consistent.– Singular not plurals

• Names should not be ambiguous.– Is “Supplier’s ID” the same as “ID of Supplier”?

• Check names are not semantically misleading. – “Product Number” may not be a number, so “Product

Identifier” is better. • Qualify names to clarify the context of use.

– “Customer Party” is more meaningful than “Customer”.

04/04/08

ebXML Naming Rules

• ebXML Core Components naming rules are an application of ISO 11179.

• All Information Entities get a Dictionary Entry Name (DEN).

• Dictionary Entry Names are globally unique.• They are the ‘key’ or unique identifier for any

Information Entity.

04/04/08

Dictionary Entry Names

{qualifier} Object Class Term, “. ”, {qualifier} Property Term, “. ”, {qualifier} Representation Term

• Object Class Term– The object class to which it belongs.

• Property Term– Reflecting its function as a property or distinguishing characteristic

of the object class.• Representation Term

– How it is represented.

04/04/08

UBL DesignRepresentation Terms

Amount

The version of the UN/ECE rec. 9 code list.Amount. Currency. Code List Version Identifier

The currency of the amount.Amount. Currency. Identifier

A number of monetary units specified in a currency where the unit of currency is explicit or implied.

Content

<cbc:TaxAmount currencyID="DKK">1262.50</cbc:TaxAmount>

Binary Object(Graphic, Picture, Sound, Video)

The filename of the binary object.Binary Object. Filename. Text

The Uniform Resource Identifier that identifies where the binary object is located.

Binary Object. Uniform Resource. Identifier

The character set of the binary object if the mime type is text.

Binary Object. Character Set. Code

Specifies the decoding algorithm of the binary object.

Binary Object. Encoding. Code

The mime type of the binary object.Binary Object. Mime. Code

The format of the binary content.Binary Object. Format. Text

A set of finite-length sequences of binary octets.Binary Object. Content

<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" encodingCode="Base64" characterSetCode="UTF-8">brIG0Ng53KHKaoOQNQYcpyFHKa9UhkgzjkPBTaFJDIBUasfdgartujjuoprrwer34578deewcwetyuuutyur643432THyB4KY5SYM5BZcpMkshU0UzJoLHSDEWFdreefssd///</cbc:EmbeddedDocumentBinaryObject>

The name of the agency that maintains the code list.

Code List. Agency Name. Text

An agency that maintains one or more code lists.

Code List. Agency. Identifier

The identification of a list of codes.Code List. Identifier

A character string (letters, figures or symbols) that for brevity and/or language independence may be used to represent or replace a definitive value or text of an attribute.

Code. Content

Code (contd.)

The Uniform Resource identifier that identifies where the code list scheme is located.

Code List Scheme. Uniform Resource. Identifier

The Uniform Resource Identifier that identifies where the code list is located.

Code List. Uniform Resource. Identifier

The textual equivalent of the code content.Code. Name. Text

The version of the code list.Code List. Version. Identifier

The name of a list of codes.Code List. Name. Text

Date Time(Date, Time)

The format of the date/time content.Date Time. Format. Text

The particular point in the progression of time.

Date Time. Content

<cbc:StartDate>2007-01-25</cbc:StartDate>

Identifier

The name of the identification scheme.Identification Scheme. Name. Text

The identification of the identification scheme.Identification Scheme. Identifier

A character string used to identify and distinguish uniquely, one instance of an object in an identification scheme from all other objects within the same scheme.

Identifier. Content

<cbc:ID schemeID=”GTIN">5712345780121</cbc:ID>

Identifier (contd.)

The Uniform Resource Identifier that identifies where the identification scheme is located.

Identification Scheme. Uniform Resource. Identifier

The Uniform Resource Identifier that identifies where the identification scheme data is located.

Identification Scheme Data. Uniform Resource. Identifier

The version of the identification scheme.Identification Scheme. Version. Identifier

The name of the agency that maintains the identification scheme.

Identification Scheme. Agency Name. Text

The identification of the agency that maintains the identification scheme.

Identification Scheme Agency. Identifier

Indicator

Whether the indicator is numeric, textual or binary.

Indicator. Format. Text

The value of the indicator.Indicator. Content

<cbc:ChargeIndicator>false</cbc:ChargeIndicator>

Measure

The version of the measure unit code list.

Measure Unit. Code List Version. Identifier

The type of unit of measure.Measure Unit. Code

The numeric value determined by measuring an object.

Measure. Content

<cbc:GrossWeightMeasure unitCode="KGS">21408.79</cbc:GrossWeightMeasure>

Numeric. Content Numeric information that is assigned or is determined by calculation, counting or sequencing.

Numeric(Value, Rate, Percent)

Whether the number is an integer, decimal, real number or percentage.

Numeric. Format. Text

<cbc:PackSizeNumeric>1</cbc:PackSizeNumeric>>

Quantity

The name of the agency which maintains the quantity unit code list.

Quantity Unit. Code List Agency Name. Text

The identification of the agency that maintains the quantity unit code list.

Quantity Unit. Code List Agency. Identifier

The quantity unit code list.Quantity Unit. Code List. Identifier

The unit of the quantity.Quantity. Unit. Code

A counted number of non-monetary units possibly including fractions.

Quantity. Content

<cbc:PackQuantity unitCode="EA">1</cbc:PackQuantity>

Text(Name)

The identification of the locale of the language.

Language. Locale. Identifier

A character string (I.e. a finite set of characters) generally in the form of words of a language.

Text. Content

<cbc:Description>Nokia Mobile telephone –Type ABC</cbc:Description>

Note: The Representation term “Text” is not part of the tag name (UBL naming rule)

04/04/08

UBL Design Codes and Identifiers

04/04/08

Sets of Codes

• A special set of possible values. • The code value refers to something else.• May be symbolic representations:

– Initialisms (“EU”), – Acronyms (“SARS”), – Apocopations (“Reefer”) or – Arbitrary abbreviations (“XML”).

• But maybe not...– Both ISO code “CNY” and “156” identify the Chinese Yuan

Renminbi.

04/04/08

Codes and Values

Types of packaging codes

Units of Measurement codes

Refers to

04/04/08

Identifiers

• Have meaning in their own right.– Don’t have to reference anything.

• May be a constrained set of values:– Set of Driver’s License numbers issued.

• May be symbolic representations (like codes).• Or (effectively) not…

• The values for identifying a phone number.

• We use codes as identifiers:– Digits in phone numbers are codes for regions.

• But not identifiers as codes:– What does your Driver’s License number refer to?

04/04/08

What are these?

ABCU123456789000ABCU123456789001

ABCUIJKL123456XYZ

NHKL7654321HPGL8877665

OCLU1234567And these?Shipping Container Numbers

Waybill Numbers

04/04/08

UBL Specification

04/04/08

Specifying Documents

• We need a range of metadata to support the explanation of meanings.– Names are not enough.

• We define these in models.

04/04/08

UBL SpecificationModels and Modeling

04/04/08

• A generalized, conceptual model. – “webs” or networks.– Domain Model, Enterprise Data Model.

• Not a model of one document…but,

• A model of Information Entities usable in all documents.– and databases, etc.

• Complexity depends on the number of the business rules.

Component Models

04/04/08

A Component ModelA

cd Major Entities

«ABIE»Common Library::Item

«ABIE»Shipment

«ABIE»Goods Item

«ABIE»Consignment

«ABIE»Transport Equipment

«ABIE»Transport Means

«ABIE»Common Library::Package

«ABIE»Shipment Stage

«ABIE»Transport Handling Unit

«ABIE»Procurement Library::Line ItemP

T RA DE V IEWT

T RA NSP ORT V IEW

«ABIE»Goods Item Container

0 ..* 0 ..*

transpo rt vi ew toequ i pm en t

transpo rt vi ew to p ackage

trade view to packag e0 ..*0 ..1

trade view to i tem

0 ..*transp ort vi ew to i tem

04/04/08

UBL’s Common Components

04/04/08

UBL Specification Assembling Components

into Documents

04/04/08

Documents are Hierarchical

• Inverse tree structure.

• Can be represented in a 2D space.– That’s why markup languages need just <start> and

</end> tags.

• Nesting imposes meaning. – When “Contact” contains “Name” we know that the

name is that of the contact. – Parent (genealogy) gives contact of use.

04/04/08

Hierarchy not Network

04/04/08

cd Customer Party

«ABIE»Customer Party

# «BBIE» Customer Assigned Account ID: Identifier [0..1]# «BBIE» Supplier Assigned Account ID: Identifier [0..1]# «BBIE» Additional Account ID: Identifier [0..*]

«ABIE»Common Library::Party

# «BBIE» Mark Care Indicator: Indicator [0..1]# «BBIE» Mark Attention Indicator: Indicator [0..1]- «BBIE» Website URI: Identifier [0..1]- «BBIE» Logo Reference ID: Identifier [0..1]- «BBIE» End Point ID: Identifier [0..1]

«ABIE»Common Library::Contact

# «BBIE» ID: Identifier [0..1]# «BBIE» Name: Name [0..1]# «BBIE» Telephone: Text [0..1]# «BBIE» Telefax: Text [0..1]# «BBIE» Electronic Mail: Text [0..1]# «BBIE» Note: Text [0..1]

0..1+Buyer

0..1+Accounting

+Del ivery0..1

A Document Assembly Model

04/04/08

Another Document Assembly Model

04/04/08

Creating a Document Assembly

• Each type of document usually requires its own document assembly model.

• We create a document assembly model by:1. Choosing an “entry point” into the Document Component

Model.• The entry point is a structure that will form the root of the

document tree.

2. Following a pathway through the component model– guided by business rules for the document required.

04/04/08

• If an association is mandatory:– must follow the path– the associated ABIE must be in the document.

• If an association is optional:– may follow the path

– the associated ABIE can be in the document if required by business rules.

• Cardinality of associations controls the depth of the document hierarchy.

Assembling Associations

04/04/08

UBL Specification Assembly Patterns

04/04/08

Patterns for Document Assembly

• Document assembly models express business rules based on the context of use.

• Many assemblies share common structures. – There are patterns of assemblies. – a Book, a Contract, an Order.

• Good designers employ these patterns…

– Because processes will find their documents familiar.

04/04/08

The “Book” Assembly PatternT

cd Book Assembly Pattern

Text Book

Foreword Preface Introduction Chapter Appendix Bibliography Index

Section Exercise

0..1 0..1 1 1..* 0..1 0..1 0..1

0..* 0..*

04/04/08

Reusing Assembly Patterns

• Assembly patterns encourages the use of common libraries of components. – Reusing patterns from elsewhere in the model

– Adopting patterns from outside

• The challenge is customizing these patterns to suit specific requirements.

designing business documents with ublevents.oasis-open.org/home/sites/events.oasis-open.org... ·...

Documents

ubl report

ubl sponsors pakistan vs. world xi series … · ubl...

ubl ndr version 1pt0 -...

mashups for composite enterprise...

universal business language version...

designing business documents with ubl - oasis...

attribute declaration...

universal business language version 2 -...

universal business language (ubl) 2.0 naming and design...

ubl 2 guidelines for customization, first edition -...

news and improvements 8.00 - amesto · pdf filevisma...

universal business language version 2 - docs.oasis...

ubl 1 -...

universal business language v2 -...

˘ ˇ ˆ -...

business document naming and design rules...

egov-bus: advanced egovernment information service...

a standard for web services transactions dr mark little...

universal business language version 2 -...

universal business language (ubl) 2.0 naming and design...