[Accessibility conventions are described at the bottom of the page]
3. Information items
[> 4.][< 2.3.2][^^^]
3.0 Information found in UBL documents
[> 3.1][> 4.][< 3.][^^][^^^]
Committee members are responsible for information modeling of UBL document types
[[1] - the XML document modeling is not the direct responsibility of members
[1] - XML document models are synthesized from the collaborative information models
[1] - office software spreadsheets used for collaboratively developing the information models
[1] - UML information models used for confirming the spreadsheet models
[[2] - some members start with the UML and add to the spreadsheets from their work
]]
UBL development started with the xCBL 3.0 information items
[[1] - along the way refined the concepts based on reviews and feedback from the public and from committee members
[1] - applied the principles of syntax-neutral CCTS to the definition of an XML vocabulary
[[2] - UBL is the first publicly-available royalty-free library of XML components defined using CCTS 2.01
]]
UBL keeps the innovative concept of a library of common shared information items
[[1] - document types are not developed in isolation
[1] - individual document types are built from components in a single library
[1] - ensures semantic equivalence of constructs between document types because the constructs are the same (not just similar)
]
UBL uses CCTS distinction between basic (atomic) and aggregate (molecular) constructs
[[1] - XML structures are syntactic representations of semantic building blocks of CCTS
]
3.1 Information definitions
[> 3.2][< 3.0][^^][^^^]
3.1.1 Information organization
[> 3.1.2][> 3.2][> 4.][< 3.0][^^][^^^]
Individual information entities are declared with their constituent components
[[1] - a declaration describes a parent/children or item/text relationship
[[2] - a declaration of an item with children constrain the order and quantity of children
[2] - a declaration of an item without children constrains the characters used in the string of text
][1] - one declaration per information item
[[2] - a very flat set of declarations (no "grandchildren" are ever declared)
]]
A view of the nesting of declarations using a simplified model illustrating only a few of the child constructs:
[[1] - a number of optional child constructs are omitted in this diagram, but the ones shown are those used in the associated markup
example that follows
]
[Figure 3.1: Information container declaration
A number of labeled solid-line boxes depict independent declarations of information items. Within each box is a set of zero
or more labeled dotted-line boxes depict the information items contained within the information item depicted by each outer
box.
The outer-box labels with their respective inner-box labels are as follows:
[[1] - AccountingSupplierParty
[[2] - Party
][1] - AccountingCustomerParty
[[2] - Party
][1] - Party
[[2] - PartyName
[2] - PostalAddress
][1] - PartyName
[[2] - Name
][1] - PostalAddress
[[2] - StreetName
[2] - AdditionalStreetName
[2] - BuildingNumber
[2] - CityName
[2] - PostalZone
[2] - CountrySubentity
[2] - Country
][1] - Country
[[2] - IdentificationCode
][1] - Name
[1] - IdentificationCode
[1] - CountrySubentity
[1] - Country
[1] - StreetName
[1] - AdditionalStreetName
[1] - BuildingNumber
[1] - CityName
[1] - PostalZone
]
]
Structured information is maintained in a tree organization of repeating parents
[[1] - the tree can be considered as upside down with the root above the top-most branch
[[2] - branches and leaves reach down the diagram
[2] - sometimes the tree is drawn from side to side
[[3] - the triangles in the diagrams of this material are meant to evoke the branching of structured information from left to right,
with the root at the left and the leaves at the right
]][1] - branches of the tree are containers of containers
[[2] - structural constraints on the order and quantity of child constructs
][1] - leaves of the tree are containers of text
[[2] - lexical constraints on the characters used in the string of text
]]
[Figure 3.2: Information container use
The nesting of two boxes depicts the nesting of repeated information items in different document contexts. The boxes are nested
as follows:
[[1] - AccountingSupplierParty
[[2] - Party
[[3] - PartyName
[[4] - Name
][3] - PostalAddress
[[4] - StreetName
[4] - AdditionalStreetName
[4] - BuildingNumber
[4] - CityName
[4] - PostalZone
[4] - CountrySubentity
[4] - Country
[[5] - IdentificationCode
]]]][1] - AccountingCustomerParty
[[2] - Party
[[3] - PartyName
[[4] - Name
][3] - PostalAddress
[[4] - StreetName
[4] - BuildingNumber
[4] - CityName
[4] - PostalZone
[4] - CountrySubentity
[4] - Country
[[5] - IdentificationCode
]]]]]
]
Information items are used as many times as needed
[[1] - still only one declaration per item regardless of how often the item is used
[[2] - e.g. the StreetName item exists twice in the collection above
[[3] - once nested three levels deep under AccountingSupplierParty
[3] - once nested three levels deep under AccountingCustomerParty
]][1] - an instance is not obliged to have optional information items
[[2] - e.g. the AdditionalStreetName is not a part of the address for the AccountingCustomerParty
]]
Each of the uses of an object describes a document context
[[1] - any given information item has a single document context from the outermost container through all of the nested containers
to the item
[1] - different use of the noun "context" for "document context" than for "business context"
[[2] - structured information uses the term "document context" for the differing locations of information items
[2] - business process description uses the term "business context" for the differing applications of rules
]]
The following is a subset of document contexts excerpted from an XPath text file
[[1] - defined formally in [Chapter 7.]
]
[Example 3-1: 01 AccountingSupplierParty
02 AccountingSupplierParty/Party
03 AccountingSupplierParty/Party/PartyName
04 AccountingSupplierParty/Party/PartyName/Name
05 AccountingSupplierParty/Party/PostalAddress
06 AccountingSupplierParty/Party/PostalAddress/StreetName
07 AccountingSupplierParty/Party/PostalAddress/AdditionalStreetName
08 AccountingSupplierParty/Party/PostalAddress/BuildingNumber
09 AccountingSupplierParty/Party/PostalAddress/CityName
10 AccountingSupplierParty/Party/PostalAddress/PostalZone
11 AccountingSupplierParty/Party/PostalAddress/CountrySubentity
12 AccountingSupplierParty/Party/PostalAddress/Country
13 AccountingSupplierParty/Party/PostalAddress/Country/IdentificationCode
14 AccountingCustomerParty
15 AccountingCustomerParty/Party
16 AccountingCustomerParty/Party/PartyName
17 AccountingCustomerParty/Party/PartyName/Name
18 AccountingCustomerParty/Party/PostalAddress
19 AccountingCustomerParty/Party/PostalAddress/StreetName
20 AccountingCustomerParty/Party/PostalAddress/BuildingNumber
21 AccountingCustomerParty/Party/PostalAddress/CityName
22 AccountingCustomerParty/Party/PostalAddress/PostalZone
23 AccountingCustomerParty/Party/PostalAddress/CountrySubentity
24 AccountingCustomerParty/Party/PostalAddress/Country
25 AccountingCustomerParty/Party/PostalAddress/Country/IdentificationCode
]
The XML markup reflects the nesting of containers
[[1] - corresponding to the uses of the information items in each document context
[1] - note that the indentation is irrelevant
]
[Example 3-2: 01 <cac:AccountingSupplierParty>
02 <cac:Party>
03 <cac:PartyName>
04 <cbc:Name>Consortial</cbc:Name>
05 </cac:PartyName>
06 <cac:PostalAddress>
07 <cbc:StreetName>Busy Street</cbc:StreetName>
08 <cbc:AdditionalStreetName>East of Main</cbc:AdditionalStreetName>
09 <cbc:BuildingNumber>56A</cbc:BuildingNumber>
10 <cbc:CityName>Farthing</cbc:CityName>
11 <cbc:PostalZone>AA99 1BB</cbc:PostalZone>
12 <cbc:CountrySubentity>Heremouthshire</cbc:CountrySubentity>
13 <cac:Country>
14 <cbc:IdentificationCode>GB</cbc:IdentificationCode>
15 </cac:Country>
16 </cac:PostalAddress>
17 </cac:Party>
18 </cac:AccountingSupplierParty>
19 <cac:AccountingCustomerParty>
20 <cac:Party>
21 <cac:PartyName>
22 <cbc:Name>IYT Corporation</cbc:Name>
23 </cac:PartyName>
24 <cac:PostalAddress>
25 <cbc:StreetName>Avon Way</cbc:StreetName>
26 <cbc:BuildingNumber>56A</cbc:BuildingNumber>
27 <cbc:CityName>Bridgtow</cbc:CityName>
28 <cbc:PostalZone>ZZ99 1ZZ</cbc:PostalZone>
29 <cbc:CountrySubentity>Avon</cbc:CountrySubentity>
30 <cac:Country>
31 <cbc:IdentificationCode>GB</cbc:IdentificationCode>
32 </cac:Country>
33 </cac:PostalAddress>
34 </cac:Party>
35 </cac:AccountingCustomerParty>
]
3.1.2 Basis of interoperability
[> 3.1.3][> 3.2][> 4.][< 3.1.1][^][^^][^^^]
UBL is the first published set of publicly-available XML schemas to express in XML syntax instantiations of the syntax-neutral
ebXML core components (CCTS v2.01)
[[1] - core component types
[[2] - the set of information types from which all information types are derived
[[3] - e.g. currency amount, text, numeric, date, etc.
][2] - "supplementary components" are the meta data of the value in the instance
[[3] - e.g. currency of the currency amount
]][1] - core components
[[2] - building blocks for semantic description of a specific concept
[2] - aggregate core component
[[3] - collection of related pieces of business information
[3] - representation of an object class
][2] - basic core component
[[3] - singular business characteristic of an aggregate core component
][2] - association core component
[[3] - complex business characteristic of an aggregate core component
[3] - represents the use of an aggregate core component
]][1] - business information entities
[[2] - building blocks for business data
[2] - aggregate business information entity (ABIE)
[[3] - collection of related pieces of business information
[3] - representation of an object class
][2] - basic business information entity (BBIE)
[[3] - singular business characteristic of an aggregate business information entity
][2] - association business information entity (ASBIE)
[[3] - complex business characteristic of an aggregate business information entity
[3] - represents the use of an aggregate business information entity
]]]
The association construct is the mechanism by which an aggregate construct is referenced as part of another aggregate construct
[[1] - a distinction is made in modeling so as not to confuse the role of an aggregate definition
[1] - the aggregate entry in the model is the definition of the aggregate
[1] - the association entry in the model is a reference to the aggregate
]
Declarations exist for only ABIE and BBIE entities
[[1] - ASBIE entities in ABIE entities reference other ABIE entities
]
Derivation of business information entities from core components:
[[1] - note that the "Document ABIE" is the outermost ABIE that is not referenced as an ASBIE from any other ABIE
[[2] - e.g. "Invoice"
]]
[Figure 3.3: Core component derivation
Two sets of boxes depict, respectively, the definitions of business objects and the definitions of core components.
Under "Business Definitions", the "Aggregate Business Information Entity (ABIE)" box is shown to be defined as an "Aggregate
Core Component" under "Core Definitions". Similarly, the "Association Business Information Entity (ASBIE)" box is shown to
be defined as an "Association Core Component", and the "Basic Business Information Entity (BBIE)" as a "Basic Core Component".
Under "Core Definitions", the concept represented by the box "Core Component" is shown to be used in a "Basic Core Component",
and both the "Basic Core Component" and "Association Core Component" is used in the "Aggregate Core Component".
Under "Business Definitions", concepts represented by the boxes "Basic Business Information Entity (BBIE)" and "Association
Business Information Entity (ASBIE)" are shown to be used in the "Aggregate Business Information Entity (ABIE)". Behind the
"Aggregate Business Information Entity (ABIE)" box is a box labeled "Document ABIE" to represent that ABIE not used as an
ASBIE by any other ABIE.
]
Examples of UBL business information entities
[[1] - <cac:Party> defined by the ABIE named "Party. Details"
[[2] - contains <cac:PostalAddress> defined by the ASBIE named "Party. Postal_ Address. Address" which references the ABIE named "Address. Details"
][1] - <cac:PostalAddress> defined by the ABIE named "Address. Details"
[[2] - contains <cbc:AdditionalStreetName> defined by the BBIE named "Address. Additional_ Street Name. Name"
][1] - recall the markup in [Example 3-2] used to represent these items
]
3.1.3 CCTS definitions
[> 3.1.4][> 3.2][> 4.][< 3.1.2][^][^^][^^^]
[[1] - version 2.01 of CCTS in play when UBL 2.0 development began
]
CCTS prescribes the description of a component to have the following information:
[[1] - without including anything about syntax
[[2] - CCTS abstract concepts are designed to be realized in a concrete syntax
][1] - dictionary entry name ("DEN") conventions based on ISO/IEC 11179 Part 5
[[2] - Naming and identification Principles for data elements
[[3] - name built on three components
[[4] - usually: object, function, type
[4] - also: activity, characteristic, form
]][2] - Qual_ Object Class. Qual_ Property Term. Representation Term
[2] - e.g. "Address. Additional_ Street Name. Name"
[2] - name structure:
[[3] - usually: (Qualifier)_ (Object). (Qualifier)_ (Function). (Type)
[3] - also: (Qualifier)_ (Activity). (Qualifier)_ (Characteristic). (Form)
][2] - three name major components:
[[3] - object class/activity: logical data grouping or aggregation
[3] - function/characteristic: distinguishing property of the object class
[3] - type/form: describes the shape of the information at a lexical text-string level
[3] - some components may be qualified
][2] - dictionary entries in English using the Oxford English Dictionary
][1] - definition
[[2] - unique business semantic of the core component
][1] - cardinality
[[2] - mandatory/optional
[2] - singleton/repeatable
[2] - four combinations represented symbolically by postfix Kleene operators
[[3] - mandatory and not repeatable - 1 - (no Kleene postfix operator)
[3] - optional and not repeatable - 0..1 - "?"
[3] - mandatory and repeatable - 1..n - "+"
[3] - optional and repeatable - 0..n - "*"
][2] - note that while a cardinality may be explicitly repeatable - e.g. 0..7 for up to 7 uses of the item - this is not used in UBL
[[3] - regarded as a facet of business rule checking to check arbitrary conditions
[[4] - e.g. arbitrary cardinality
[4] - e.g. field length
]]][1] - business terms (optional)
[[2] - commonly-known synonym term used in business
[2] - there may be several terms or synonyms for a single core component
]]
3.1.4 UBL definitions
[> 3.1.5][> 3.2][> 4.][< 3.1.3][^][^^][^^^]
UBL component definition (derived from [CCTS definitions - Section 3.1.3]):
[[1] - UBL name (e.g. "AdditionalStreetName")
[[2] - calculated from the dictionary entry name
[2] - object class and punctuation are dropped
[2] - some abbreviations (e.g. "ID" for "Identifier")
[2] - rules remove duplicate parts of a complete name
[[3] - e.g. when the representation term is the same as the end of the property term
]][1] - definition in prose
[[2] - written in English
[2] - see [Chapter 6.] regarding translations
][1] - component type
[[2] - BBIE, ASBIE or ABIE
][1] - dictionary entry name (e.g. "Address. Additional_ Street Name. Name")
[[2] - object class portion
[[3] - class qualifier (optional)
[[4] - in the end this was never used by the UBL TC
][3] - class name (e.g. "Address.")
][2] - property term portion (e.g. "Additional_ Street Name.")
[[3] - property term qualifier (optional) (e.g. "Additional_")
[3] - property term (e.g. "Street Name.")
[[4] - property term possessive noun (e.g. "Street")
[4] - property term primary noun (e.g. "Name.")
]][2] - representation term portion (e.g. "Name")
[[3] - i.e. this information item "is represented by an amount value"
[3] - e.g. amount (currency), identifier, text, name, etc.
[3] - the representation term isn't supposed to convey any semantics or meaning
[3] - aggregate items use the representation term "Details"
]][1] - qualified data type
[[2] - data type qualifier (optional)
[2] - data type (e.g. "Name. Type")
[2] - describes the set of valid values for a BBIE
[2] - uses the representation term
][1] - cardinality (e.g. "0..1")
[[2] - how often the information item occurs
][1] - business terms (e.g. "thoroughfare")
[1] - example value (e.g. "Corner of Aberdeen Road")
]
Object class + Property term = sufficient recognition of an item
[[1] - doesn't replace the definition but should be distinctly recognizable for its purpose
[[2] - the associated definition is the formal normative definition for the item
][1] - Representation term only identifies the structure of the item
[[2] - only used when distinguishing the property term as being a particular structure of a different name
[2] - an absent representation term infers that the representation term is identical to the property term
]]
Important rule of thumb when developing compatible customizations
[[1] - when creating new elements that are not elements in UBL
[1] - dictionary entry naming techniques should follow practices followed by the UBL committee
[[2] - see [Dictionary entry naming - Section 12.2.2] for more detail
][1] - UBL naming is automated from the dictionary entry name
]
3.1.5 UBL information item constraints
[> 3.2][> 4.][< 3.1.4][^][^^][^^^]
Aggregate items (ABIE) are defined as a sequence of child items each with cardinality
[[1] - BBIE children have simple text values
[[2] - text values are of a particular core component data type
][1] - ASBIE children are ABIE items with item children
[[2] - no mixed content in any UBL information item
[[3] - i.e. no mixing of items and sibling text
[3] - e.g. no "bold" or "italic" constructs for highlighting content
]]]
BBIE data types restrict the text expression of the value
[[1] - amount (currency)
[1] - binary object type
[1] - code
[1] - date
[1] - identifier
[1] - indicator
[1] - measure
[1] - name
[1] - numeric
[1] - percent
[1] - quantity
[1] - rate
[1] - text
[1] - time
[1] - others defined in the CCTS standardized set of unqualified core component data types are not used in UBL 2.0
]
No cultural preferences are allowed in numeric values
[[1] - decimal separator is always "."
[1] - no thousands punctuation
[1] - no other punctuation
[[2] - currency is indicated using a supplementary component and is expressed using an attribute
]]
Coded-value item and identifier-value item values are mnemonic or representative of semantics or lookup values
[[1] - information items defined by values from code lists or identifier lists are popular in many business documents
[1] - a single value is expressed as a sequence of characters possibly with embedded single spaces
[1] - also known as "controlled vocabularies"
]
A coded-value item's data type is either qualified (when a code list has been suggested by the UBL TC) or unqualified (when
a code list has not been suggested by the UBL TC)
[[1] - initial values are provided by UBL TC for qualified coded value data types
[[2] - not a normative aspect of the UBL definition
][1] - a predefined set of values available only to be restricted
[[2] - e.g. Currency_ Code. Type
[[3] - initially defined set of values to be all currencies of the world
]][1] - a predefined set of values available to be supplemented or restricted
[[2] - e.g. Document Status_ Code. Type
[[3] - values "Cancelled", "Disputed", "NoStatus", and "Revised"
][2] - e.g. Payment Means_ Code. Type
[[3] - values "10" (cash), "20" (cheque), etc.
]][1] - a limited set of values unlikely to be changed
[[2] - e.g. Latitude Direction_ Code. Type
[[3] - values "North" and "South"
][2] - e.g. Longitude Direction_ Code. Type
[[3] - values "East" and "West"
]][1] - no defined values but available to be defined between trading partners
[[2] - e.g. Code. Type for Invoice. Invoice_ Type. Code
]]
None of the identifier types have any initial values suggested by the committee
[[1] - e.g. account numbers, customer numbers, etc.
]
3.2 Information maintenance
[> 3.3][< 3.1.5][^^][^^^]
3.2.1 ABIE re-use report
[> 3.2.2][> 3.3][> 4.][< 3.1.5][^^][^^^]
[http://docs.oasis-open.org/ubl/os-UBL-2.0/etc/UBL-ABIE-Reuse-Table-2.0.ods]
[http://docs.oasis-open.org/ubl/os-UBL-2.0/etc/UBL-ABIE-Reuse-Table-2.0.xls]
Summary cross-reference report of the use and re-use of aggregate business information entities:
[[1] - most aggregate items use other aggregate items through associated proxies
[1] - re-use report summarizes the aggregate items used by other aggregate items and the aggregate items using other aggregate items
[1] - does not summarize the use of basic items
]
3.2.2 Library of shared and specific information items
[> 3.2.3][> 3.3][> 4.][< 3.2.1][^][^^][^^^]
UBL maintains two collections of sets of information items
[[1] - the top-level document type ABIE items are separate from the common lower-level BBIE items and the ABIE items used as ASBIE
items
[1] - recall the diagram on [Figure 3.3] distinguishing the document ABIE items
]
A collection of document type sets of items that make use of the shared libraries
[[1] - the collection is referred to as "maindoc"
[1] - one set of information item definitions per document type
[[2] - only one top-level document ABIE information item per document type
][1] - the document type ABIE items are not used anywhere as ASBIE items
]
A collection of shared libraries of items
[[1] - the collection is referred to as "common"
[1] - one library includes the definition of all BBIE items and ABIE items that are used as ASBIE items
[[2] - the UBL 2.0 common library defines 113 ABIE items used by document types and other library items
][1] - one module includes the declarations of qualified data types
[[2] - meta data for UBL-suggested qualified code lists
[2] - no code list values
]]
An office software spreadsheet is used to maintain the details of items in a set
[[1] - each row of a spreadsheet maintains one ABIE, BBIE or ASBIE information item
[1] - the columns of the spreadsheet describe the properties of each information item
[1] - one of the two normative components of UBL is the spreadsheets used to maintain the definitions
[[2] - the focus of collaboration is on the information being maintained by UBL
[2] - the spreadsheets are not normative as they only determine and govern the XML structures but they do not, in and of themselves,
express the mechanics of the XML structures
[[3] - the focus of UBL standardization is the interchange of information in an XML document
[3] - the semantics and the collaboration guide the determination of the interchange but do not define the actual interchange syntax
][2] - all aspects of interchange syntax and XML message construction are synthesized from the collaboration stylesheets
[[3] - the other normative component of UBL is the set of W3C Schema XSD expressions to be described on [Document model formal expressions - Section 5.0 Document model formal expressions]
]][1] - the spreadsheets are input to automated processes that synthesize the formal document model constraint schema syntax
[[2] - not all column values are copied into the schema
[2] - columns with yellow headers are copied, columns with gray headers are not
]]
http://docs.oasis-open.org/ubl/os-UBL-2.0/mod/maindoc directory
[[1] - one module of information items for each specific document type and document ABIE
[1] - each document type makes reference into the shared library for common components
[[2] - unique components are defined for each document type
][1] - UBL-ApplicationResponse
[1] - UBL-AttachedDocument
[1] - UBL-BillOfLading
[1] - UBL-Catalogue
[1] - UBL-CatalogueDeletion
[1] - UBL-CatalogueItemSpecificationUpdate
[1] - UBL-CataloguePricingUpdate
[1] - UBL-CatalogueRequest
[1] - UBL-CertificateOf Origin
[1] - UBL-CreditNote
[1] - UBL-DebitNote
[1] - UBL-DespatchAdvice
[1] - UBL-ForwardingInstruction
[1] - UBL-FreightInvoice
[1] - UBL-Invoice
[1] - UBL-Order
[1] - UBL-OrderCancellation
[1] - UBL-OrderChange
[1] - UBL-OrderResponse
[1] - UBL-OrderResponseSimple
[1] - UBL-PackingList
[1] - UBL-Quotation
[1] - UBL-ReceiptAdvice
[1] - UBL-Reminder
[1] - UBL-RemittanceAdvice
[1] - UBL-RequestForQuotation
[1] - UBL-SelfBilledCreditNote
[1] - UBL-SelfBilledInvoice
[1] - UBL-Statement
[1] - UBL-TransportationStatus
[1] - UBL-Waybill
]
http://docs.oasis-open.org/ubl/os-UBL-2.0/mod/common directory
[[1] - information items common to all document types
[1] - UBL-CommonLibrary
[[2] - parties, contacts, addresses, locations, dimensions, tax information, etc.
][1] - UBL-qDT
[[2] - "qualified data types"
[2] - definitions of values for code list meta data for those code lists for which the UBL TC provides values
[[3] - AllowanceReasonCode
[3] - ChannelCode
[3] - ChipCode
[3] - ContainerSizeTypeCode
[3] - CountryIdentificationCode
[3] - CurrencyCode
[3] - DocumentStatusCode
[3] - LatitudeDirectionCode
[3] - LineStatusCode
[3] - LongitudeDirectionCode
[3] - OperatorCode
[3] - PackagingTypeCode
[3] - PaymentMeansCode
[3] - PortCode
[3] - SubstitutionStatusCode
[3] - TransportationStatusCode
[3] - TransportEquipmentTypeCode
[3] - TransportModeCode
[3] - UnitOfMeasureCode
][2] - note there isn't a qualified data type for BinaryObjectMimeCode yet there is such a code list
[[3] - this is an unqualified supplementary component of the BinaryObjectType defined by UN/CEFACT
]]]
3.2.3 UBL information model spreadsheets
[> 3.2.4][> 3.3][> 4.][< 3.2.2][^][^^][^^^]
Two spreadsheet documents capture information regarding each single shared or specific library collection:
[[1] - same information in both spreadsheets, only different file formats for different tools
[1] - useful for collaboration between business experts who are not document or model experts
[1] - .ods - Open Document Format (ODF) Spreadsheet
[1] - .xls - Microsoft Excel Spreadsheet
]
Color conventions
[[1] - magenta row - ABIE
[1] - white row - BBIE
[1] - cyan row - ASBIE
[1] - yellow-headed column - value copied to embedded schema documentation
]
Example from UBL-CommonLibrary (e.g. row 10 has AdditionalStreetName):
[Figure 3.4: Collaboration spreadsheet screenshot
A screenshot of the spreadsheet is shown.
]
Rows ordered by object class
[[1] - no specific order within object class
]
Columns of interest:
Informal mnemonic
[[1] - UBL Name
]
Formal name
[[1] - Dictionary Entry Name
[1] - Object Class Qualifier
[1] - Object Class
[1] - Property Term Qualifier
[1] - Property Term Possessive Noun
[1] - Property Term Primary Noun
[1] - Property Term
[1] - Representation Term
[1] - Data Type Qualifier
[1] - Data Type
[1] - Associated Object Class Qualifier
[1] - Associated Object Class
]
Properties
[[1] - Alternative Business Terms
[[2] - other simple names by which the construct is known
][1] - Cardinality
[[2] - how often the item is allowed to occur
][1] - Component Type
[[2] - BBIE, ASBIE or ABIE
][1] - Definition
[[2] - natural-language description
][1] - Examples
[[2] - representative sample values
][1] - Current Version
[[2] - when introduced into UBL use
]]
3.2.4 UBL UML information models
[> 3.3][> 4.][< 3.2.3][^][^^][^^^]
Unified Modeling Language (UML) expressions of the information models are found in http://docs.oasis-open.org/ubl/os-UBL-2.0/uml/
[[1] - standalone JPEG files illustrating the structure diagrams
[1] - interlinked HTML files that reference the JPG files
]
[Figure 3.5: Address UML diagram
A screen shot shows a UML diagram showing the "Address" ABIE.
]
UML drawing conventions
Compare the rows in the spreadsheet for CustomerParty:
[Figure 3.6: Customer Party spreadsheet rows
A screen shot shows the complete CustomerParty ABIE from lines 262 through 269 of the common library spreadsheet
]
With the matching UML drawing for CustomerParty:
[Figure 3.7: Customer Party UML diagram
A screen shot shows the CustomerParty UML model showing one ASBIE connection to the Party model and three ASBIE connections to the Contact model.
]
3.3 Crane's UBL information model reports
[> 4.][< 3.2.4][^^][^^^]
3.3.1 Crane's UBL information model reports
[> 4.][< 3.2.4][^^][^^^]
Crane Softwrights Ltd. has created an aggregated report from all document models into a single file to be viewed from a web
browser
[[1] - [http://www.CraneSoftwrights.com/resources/ubl/#ubl2modelreport]
[1] - Crane-UBL2Reports/EN/Crane-UBL2Report-All-EN.html - 5Mb (complete; all document types in one)
[1] - Crane-UBL2Reports/EN/Crane-UBL2Report-???????-EN.html - individual document types
[1] - alphabetically indexed by UBL Name and document type
[1] - hyperlinked to model row reproduction in an HTML table (juggled columns)
[1] - hyperlinked to ABIE for each ASBIE, and row numbers to index definitions
[1] - available in all languages of the IDD
]
Multilingual versions of the report
[[1] - the suffix is the two-character language indicator
[1] - the only columns translated are the definition and common business terms
]
Report has three main sections
[[1] - front matter (indexes, meta data, etc.)
[1] - alphabetized initial two-letters of each component
[1] - alphabetized link to the model collections included in the report
]
Trimmed common library component rows
[[1] - only those common library rows that are used directly or indirectly for the document types are included
[1] - this improves the traversal through the model as unused rows do not distract the reader
[[2] - e.g. the catalogue-related rows are not included directly or indirectly in the invoice report
][1] - in the report for a customized schema, the trimming includes all unused constructs
]
Rules of thumb for navigation
[[1] - hyperlinked row numbers switch between summary and table views
[1] - hyperlinked UBL names stay within the summary and table views
]
Created by Crane's schema subset configuration tool
[[1] - see [Chapter A.]
[1] - the same report is generated for an arbitrary customization of the schemas
]
[Figure 3.8: Crane model summary report screenshot
A screen shot shows portions of the index, copyright and first few information items of the Crane report.
]
This is an accessible version of Crane's commercial training material.
The content has been specifically designed to assist screen reader software
in viewing the entire textual content. Figures are replaced with text
narratives.
Navigation hints are in square brackets:
[Tx.x] and [Fx.x] are textual representations of the applicability icons;
[digit] indicates list depth for nested lists;
[link [URL]] indicates the URL of a hyperlink if different than link;
[EXAMPLE] indicates an example listing of code;
[FIGURE] indicates the presence of a figure replaced by its description;
[>] jumps forward;
[<] jumps backward;
[^] jumps to start of the section;
[^^] jumps to the start of the chapter;
[^^^] jumps to the table of contents.
Suggestions for improvement are welcome:
[info@CraneSoftwrights.com]
Book sales: [http://www.CraneSoftwrights.com/links/trn-acc.htm]
Information: [http://www.CraneSoftwrights.com/links/info-acc.htm]
This content is protected by copyright and, as there are no means to protect
this accessible version from plagiarism, please do not make any
commercial edition available to others.
+//ISBN 1-894049::CSL::Presentation::UBL//DOCUMENT Practical Universal Business Language Deployment 2009-02-12 13:50UTC//EN
Practical Universal Business Language Deployment
Third Edition - 2009-02-12
ISBN 978-1-894049-23-8
Copyright © Crane Softwrights Ltd.