The OASIS Universal Business Language [UBL 2.0] defines a family of powerful, flexible and large document types to provide for many possible uses of information in business documents.

Not all communities of users need the flexibility found in the published document models. These users can live within a smaller set of information items in each document type based on the scenario in which they are using business documents. This smaller set may vary for a given document type based on the scenario where the business document is used.

Unlike other approaches that synthesize all of the schema declarations from the spreadsheet definitions of the business objects, this "Simplified UBL schema customization" environment defines a pruning process. This pruning process produces customization schema expressions direct from the original UBL schema expressions published by the UBL Technical Committee by commenting out constructs that are not needed in a customization. This pruning process is based on a spreadsheet specification of which UBL constructs are in and not in the customization.

A demonstration of this subset environment is included in the ZIP package in which this documentation is found. Two illustrative customizations, complete with a functional (but fictional) non-UBL extension, is defined. By mimicking the customization spreadsheet and the extension schema fragments, one can define and use one's own set of OASIS UBL customizations.

A set of office document spreadsheets [CustSpread] in the UBL Technical Committee repository can be used to specify the standardized UBL constructs that are in and not in a set of UBL customizations one might maintain for different profiles. The documentation accompanying the spreadsheets has the detailed instructions.

Two kinds of subsets can be specified using the spreadsheets: a "strict" subset defining those information items that a community defines as the core of a customization, and a "permitted" subset defining items in addition to core items that are allowed to be present if users wish, but are not expressly part of the customization definition. Neither subset includes those standardized information items that are expressly excluded from the customization.

The spreadsheets have a customization "Usage" column in which an information item's applicability is indicated using a string value. The string value "USED" indicates the item is part of the strict subset of the customization. The string value "EXCLUDED" indicates the item is not a part of any subset of the customization. The empty string (an empty cell) indicates the item is part of the permitted subset of the customization.

The spreadsheets have a customization "Cardinality" column in which an information item's cardinality is indicated using the same notation as the original cardinality column. Mandatory and non-repeating objects have a cardinality of "1". Other typical cardinality indications are "0..1", "0..n" and "1..n". Any numeric value can be used for these provided the minimum number is less than or equal to the maximum number, and both are inclusively within the original values of cardinality.

The spreadsheet customization "Usage" column is initialized with all mandatory constructs having "USED" and all optional constructs having "EXCLUDED". The spreadsheet customization "Cardinality" column is initialized with the original cardinality. The specification of a subset is accomplished by modifying the cardinalities of all information items as desired, and indicating those optional constructs that are part of the strict or permitted customizations.

Any given community of UBL users may have multiple customizations of the same document model. When a community has a number of profiles of business exchanges, a given document model (say Invoice) might have more available constructs to be used in a complex procurement scenario than those used in a simple procurement scenario. Multiple customization subsets can be specified in a single spreadsheet, distinguished by unique prefixes attached to each of the "Usage" and "Cardinality" columns specifying the customization. Given that the spreadsheets are locked when downloaded from the OASIS web site, it is necessary to temporarily unlock the spreadsheet, duplicate the columns as many times as required, then locking the spreadsheet again to prevent damage to other rows. Note that in some spreadsheets one must delete the apparent (but not actually) empty columns appearing after the UBL columns to make room for the new columns to be inserted.

The demonstration spreadsheets illustrate two customizations of the Invoice document model and common library. There are two pairs of Usage/Cardinality columns, the first prefixed with "Demo1-" and the second prefixed with "Demo2-". The demonstration process produces two sets of schema documents, one for each customization, and differing based on the

The processes involved in creating a new suite of schema fragments from the published suite of schema fragments is outlined in Figure 1, “Process Overview (no extensions)”. The box labeled "Pruning Process" is the Ant [Ant] script "filterXSDDK.xml", named to indicate the Danish provenance of some of the program fragments that were used. Though a Linux version is not included with this package, the compact batch files invoking this script can be easily converted into shell scripts. The invoked flow managed using Ant is implemented in Java and portable across all Java environments.

Figure 1. Process Overview (no extensions)

Shown in the diagram are the customization specification spreadsheets, the UBL XSD schema fragments, and the customization XSD schema fragments. The XSD fragments in the customization that are different than the UBL fragments are indicated as "XSD'".

Extensions are defined for a customization when a required business object (be it optional or mandatory) cannot be found in the UBL set of predefined business objects. All UBL document types have an extension point under which extensions are declared when necessary. Not all customizations have extensions, and in fact, very few should as the UBL specification recommends that extensions be used only when standardized constructs cannot be used.

The steps described in this section are in addition to the steps described earlier for pruning the standardized set of constructs into a customized subset of constructs.

Figure 2, “Process Supplement (with extensions)” shows how the UBL-ExtensionContentDatatype-2.0.xsd schema fragment is replaced with a schema fragment incorporating the extension constructs into the document model. As delivered by the UBL TC, this original fragment defines a wildcard that accepts any extension content from any namespace vocabulary. The replacement fragment accepts the choice between a recognized extension element and an element from any other namespace. This engages the remaining schema fragments that define the constraints on the use of the extension vocabulary.

Figure 2. Process Supplement (with extensions)

This environment takes advantage of a number of publicly-available resources, some of which are quite substantial to obtain and install.

It does not matter where these components are installed in your system. The instructions for the running of the demonstration to test the environment makes reference to the environment variables to set that engage the various components.

There is a demonstration environment included in the ZIP package in which this documentation is found. The following files specify the two demonstration customizations of UBL 2.0. Note that the scenario/makexsd.bat and utility/filterXSDDK.bat invocation files must be modified to reflect the location of your installations of software.