[Accessibility conventions are described at the bottom of the page]
13. Customization extension
[> 14.][< 12.2.2][^^^]
13.0 Customization extension
[> 13.1][> 14.][< 13.][^^][^^^]
Many uses for adding extension information to the document model
[[1] - customization augmentation
[[2] - new information items are associated with existing constructs
][1] - supplemental information
[[2] - e.g. bit image scan
[[3] - including a picture to back up the choices made in the data
][2] - e.g. legacy format
[[3] - useful for round-tripping information to different formats
]]]
13.1 Conformance vs. compatibility
[> 13.2][< 13.0][^^][^^^]
13.1.1 Conformance vs. compatibility
[> 13.1.2][> 13.2][> 14.][< 13.0][^^][^^^]
At an abstract level, a customized model is somehow different than the standard model
[[1] - certain standardized optional content is prohibited in the customization
[1] - the customization may have additional non-standardized content
]
Compatibility
[[1] - model-level interoperability
[1] - business objects in compatible models are based on UBL business objects
[1] - inevitable document constraint violations against the standard UBL schemas
[[2] - non-UBL business objects must have non-UBL names
]]
Conformance
[[1] - instance-level interoperability
[1] - business objects in conformant models are bona fide UBL business objects
[1] - no document constraint violations against the standard UBL schemas
[1] - simplest conformant schema is a pure subset without extensions
[[2] - also a good starting point to determine if extensions are even needed
]]
Implicitly a conformant customization is a compatible customization
[[1] - but a compatible customization is not a conformant customization
[[2] - due to the presence of non-UBL constructs
]]
Extensions to the document model in a compatible schema are anywhere in the document
[[1] - because they are not constrained by the standard structures
[1] - typically the information
]
Extensions to the document model in a conformant schema belong under the document extension point
[[1] - extensions should be developed using compatible schema creation techniques
[1] - good practice to learn compatible derivation methodologies
[1] - choices are available for how to capture the compatible information
[[2] - extension content is necessarily separate from the standardized content
[2] - standardized content may be duplicated with the extended content
]]
13.1.2 Illustration of extension approaches
[> 13.2][> 14.][< 13.1.1][^][^^][^^^]
Consider the need to extend standardized invoice information with custom information
[[1] - new custom BIE entities are important to a particular community
[1] - e.g. custom line item information
]
The extended information record for the custom line item model:
[Figure 13.1: Extended model of line item information
A simple arrangement of four adjacent boxes represents the entire information record, with the boxes labeled as in the text.
]
[[1] - ID
[[2] - standardized line item identifier
][1] - Quantity
[[2] - standardized quantity information
][1] - custInfo
[[2] - customized information not found in the standard model
][1] - stdInfo
[[2] - other standardized information already found in the standard model
]]
To simplify the diagrams, other invoice information is not included
[[1] - bill to, ship to, etc.
[1] - any of the aggregates may be customized as the line item aggregate is in this example
]
A compatible instance has arbitrary content based on the model
[[1] - good derivation practices would re-use UBL constructs where the semantics are identical
[1] - no real constraint at the document level to use the UBL namespaces, but may help the reader or implementer of the customization
]
The instance structure representation for the compatible document model:
[Figure 13.2: Compatible document model of line item information
A simple tree is shown where the document element is cust:Invoice with the child cust:LineItem. That element has the four children cbc:ID, cbc:Quantity, cust:custInfo and c?c:stdInfo.
]
[[1] - cust:Invoice
[[2] - the document element is necessarily in a non-UBL namespace because the line item isn't a UBL line item
][1] - cust:LineItem
[[2] - the line item is necessarily in a non-UBL namespace because there are non-UBL children
][1] - cbc:ID
[[2] - standardized line item identifier
][1] - cbc:Quantity
[[2] - standardized quantity information
][1] - cust:custInfo
[[2] - customized information not found in the standard document
][1] - c?c:stdInfo
[[2] - other standardized information already found in the standard document
]]
A conformant instance can copy a complete compatible instance under the extension point
[[1] - pro: all information about the extended line item is found in one place in the document
[1] - con: standardized line item information is duplicated in two places in the document
[[2] - question of the integrity of the information (what if corresponding items are unequal)
]]
An instance structure representation for a conformant document model:
[Figure 13.3: Conformant document model of complete line item information
A tree is shown where the document element is the standard in:Invoice with the children ext:UBLExtensions and cac:LineItem. Below ext:UBLExtensions are three descendants in line ext:UBLExtension, cust:Invoice and cust:LineItem, under the last of which there are the four children cbc:ID, cbc:Quantity, cust:custInfo and c?c:stdInfo. Below cac:LineItem are the three children cbc:ID, cbc:Quantity and c?c:stdInfo.
]
[[1] - in:Invoice
[[2] - the UBL standard document element
][1] - cac:LineItem
[[2] - the UBL standard line item and its children
][1] - cust:Invoice
[[2] - the apex extension element is the complete compatible instance
]]
A conformant instance can keep only a fragment of the compatible instance under the extension point
[[1] - pro: no duplicated information in the instance
[1] - con: the application needs to compose the extended information record from fragments
[[2] - question of the linking/association/reference between fragments
]]
An instance structure representation for a conformant document model:
[Figure 13.4: Conformant document model of fragmented line item information
A tree is shown where the document element is the standard in:Invoice with the children ext:UBLExtensions and cac:LineItem. Below ext:UBLExtensions are three descendants in line ext:UBLExtension, cust:Invoice and cust:LineItem, under the last of which there are the two children cbc:ID and cust:custInfo. Below cac:LineItem are the three children cbc:ID, cbc:Quantity and c?c:stdInfo.
]
[[1] - cust:Invoice
[[2] - the apex extension element is necessarily in a non-UBL namespace because the line item isn't a UBL line item
][1] - cust:LineItem
[[2] - the line item is necessarily in a non-UBL namespace because there are non-UBL children
][1] - cbc:ID
[[2] - standardized line item identifier
][1] - cbc:Quantity
[[2] - standardized quantity information
][1] - cust:custInfo
[[2] - customized information not found in the standard document
][1] - c?c:stdInfo
[[2] - other standardized information already found in the standard document
]]
13.2 Deploying an extension
[> 13.3][< 13.1.2][^^][^^^]
13.2.1 Deploying an extension
[> 13.2.2][> 13.3][> 14.][< 13.1.2][^^][^^^]
Conformant customization schema structure
[[1] - start with copies of all of the UBL schemas related to a given document type
[[2] - preserving the subdirectory structure of the fragments
][1] - overwrite ABIE and BBIE definitions with the customized versions:
[[2] - restricted versions of the document, aggregate and basic schemas replace corresponding fragments
][1] - overwrite unconstrained extension specification with customized constraints:
[[2] - extended version of the content data type schema replaces the corresponding fragment
][1] - extension data type definition schemas are added to the directories
]
[Figure 13.5: Schema replacements for customization
A chart illustrating the dependencies of schema fragments has boxes for each schema file, starting with the Document Schema
box at the top representing an invoice, or an order, or other UBL document, in that document type's namespace.
The Document Schema imports the Common Aggregate Components (cac), Common Basic Components (cbc) and Common Extension Components (ext) fragments.
The Common Aggregate Components (cac) fragment imports the Common Basic Components (cbc), Unqualified Datatypes (udt) and Qualified/Specialized Datatypes (qdt) fragments.
The Common Basic Components (cbc) fragment imports the Unqualified Datatypes (udt) and Qualified/Specialized Datatypes (qdt) fragments.
The Qualified/Specialized Datatypes (qdt) fragment imports the Unqualified Datatypes (udt) fragment.
The Common Extension Components (ext) fragment imports the Common Basic Components (cbc) and Unqualified Datatypes (udt) fragments, and includes the Extension Content Datatype (ext) fragment.
Shown to the side in a box labeled "Customization Restriction Replacement Schemas" are the replacement Customization Document
Schema, Customization Aggregate Components (cac) and Customization Basic Components (cbc) fragments as required for the customization.
Shown to the side in a box labeled "Customization Extension Replacement Schemas" is a replacement Extension Content Datatype
(ext) fragment that imports Extension Datatype Definition (cust) fragments as required for the customization.
]
Compatible customization schema
[[1] - any structure is allowed because there are no constraints on namespaces
[1] - a good practice to import the UBL aggregate and basic components for re-use
]
13.2.2 Extension meta data
[> 13.2.3][> 13.3][> 14.][< 13.2.1][^][^^][^^^]
Extension meta data describes the extension without having to look in the extension
[[1] - all extension meta data is optional
[1] - declared in common/UBL-CommonExtensionComponents-2.0.xsd
]
This example contains one of each meta data item defined for extensions:
[Example 13-1: 01 <Invoice xmlns="urn:oasis:...:xsd:Invoice-2"
02 xmlns:cbc="urn:oasis:...:xsd:CommonBasicComponents-2"
03 xmlns:cac="urn:oasis:...:xsd:CommonAggregateComponents-2"
04 xmlns:ext="urn:oasis:...:xsd:CommonExtensionComponents-2"
05 xmlns:demo="urn:x-Demo:Demo">
06 <ext:UBLExtensions>
07 <ext:UBLExtension>
08 <cbc:ID>Demo1</cbc:ID>
09 <cbc:Name>Demonstration</cbc:Name>
10 <ext:ExtensionAgencyID>CSL</ext:ExtensionAgencyID>
11 <ext:ExtensionAgencyName>Crane Softwrights Ltd.
12 </ext:ExtensionAgencyName>
13 <ext:ExtensionVersionID>0.1</ext:ExtensionVersionID>
14 <ext:ExtensionAgencyURI>http://www.CraneSoftwrights.com/
15 links/res-dev.htm</ext:ExtensionAgencyURI>
16 <ext:ExtensionURI>urn:x-Demo:Demo:0.1</ext:ExtensionURI>
17 <ext:ExtensionReasonCode listURI="urn:x-Demo:Demo:ReasonCodes">1
18 </ext:ExtensionReasonCode>
19 <ext:ExtensionReason>Illustration</ext:ExtensionReason>
20 <ext:ExtensionContent>
21 <demo:Demo>
22 <demo:Thing>This is a test</demo:Thing>
23 <cbc:ID>DemoTest</cbc:ID>
24 <demo:Total currencyID="GBP">100.00</demo:Total>
25 </demo:Demo>
26 </ext:ExtensionContent>
27 </ext:UBLExtension>
28 </ext:UBLExtensions>
29
30 <cbc:ID>A00095678</cbc:ID>
31 <cbc:IssueDate>2005-06-21</cbc:IssueDate>
32 <cbc:Note>sample</cbc:Note>
33 <cac:AccountingSupplierParty>
34 <cac:Party>
35 <cac:PartyName>
36 ...
]
13.2.3 Extending a UBL document
[> 13.2.4][> 13.3][> 14.][< 13.2.2][^][^^][^^^]
Extending an existing UBL document involves only defining new constructs under the extension point
[[1] - replace the UBL standard UBL-ExtensionContentDatatype-2.0.xsd fragment with a fragment that allows one of only two elements
[[2] - the one apex element of the extension, in the extension namespace
[2] - any one element in any namespace other than the extension namespace
][1] - add a definition of the apex element used to wrap all of the extensions
[[2] - no corollary in the UBL library for this element, so this example uses a separate namespace
][1] - add a definition of the extension ABIE and ASBIE constructs
[[2] - use an extension namespace reserved for aggregate constructs
[2] - candidate additions to a future revision of UBL
][1] - add a definition of the extension BBIE constructs
[[2] - use an extension namespace reserved for basic constructs
[2] - candidate additions to a future revision of UBL
]]
[Figure 13.6: Adding schema fragments for an existing UBL document
A chart illustrating the dependencies of schema fragments has boxes for each schema file, starting with the Document Schema
box at the top representing an invoice, or an order, or other UBL document, in that document type's namespace.
The Document Schema imports the Common Aggregate Components (cac), Common Basic Components (cbc) and Common Extension Components (ext) fragments.
The Common Aggregate Components (cac) fragment imports the Common Basic Components (cbc), Unqualified Datatypes (udt) and Qualified/Specialized Datatypes (qdt) fragments.
The Common Basic Components (cbc) fragment imports the Unqualified Datatypes (udt) and Qualified/Specialized Datatypes (qdt) fragments.
The Qualified/Specialized Datatypes (qdt) fragment imports the Unqualified Datatypes (udt) fragment.
The Common Extension Components (ext) fragment imports the Common Basic Components (cbc) and Unqualified Datatypes (udt) fragments, and includes the Extension Content Datatype (ext) fragment.
The custom defined Extension Content Datatype (ext) fragment is shown to be overwriting the standard fragment of the same name, and that imports the Extension Apex (myext) fragment for the customization.
The Extension Apex imports the Extension Aggregate Components (mycac) and Extension Basic Components (mycbc) fragments.
The Extension Aggregate Components imports the Common Aggregate Components (cac), Common Basic Components (cbc) and Extension Basic Components (mycbc) fragments.
The Extension Basic Components (mycbc) fragment imports the Unqualified Datatypes (udt) fragment.
]
13.2.4 Adding a new non-UBL document
[> 13.3][> 14.][< 13.2.3][^][^^][^^^]
Adding a new non-UBL document involves defining a new document element and new constructs under the extension point
[[1] - the new document schema adds to the set of existing UBL document schemas
[[2] - use an extension namespace reserved for the document element only
[2] - this schema imports the extension aggregate and basic schemas in order to specify the use of top-level (children of the document
element) ASBIE and BBIE extension constructs
][1] - all the other modifications for an extended schema also apply as in [Extending a UBL document - Section 13.2.3]
[[2] - a separate extension namespace for aggregate and basic extension constructs
[[3] - and both different than the extension document element namespace
][2] - could choose to re-use the extension document element namespace for the extension apex element namespace if one wishes to
reduce the number of new namespaces
]]
[Figure 13.7: Adding a new document to the UBL collection
A chart illustrating the dependencies of schema fragments has boxes for each schema file, starting with the My Document Schema
box at the top representing a new non-UBL document, in that document type's namespace.
The My Document Schema imports the Common Aggregate Components (cac), Common Basic Components (cbc), Common Extension Components (ext), Extension Aggregate Components (mycac) and Extension Basic Components (mycbc) fragments.
The Common Aggregate Components (cac) fragment imports the Common Basic Components (cbc), Unqualified Datatypes (udt) and Qualified/Specialized Datatypes (qdt) fragments.
The Common Basic Components (cbc) fragment imports the Unqualified Datatypes (udt) and Qualified/Specialized Datatypes (qdt) fragments.
The Qualified/Specialized Datatypes (qdt) fragment imports the Unqualified Datatypes (udt) fragment.
The Common Extension Components (ext) fragment imports the Common Basic Components (cbc) and Unqualified Datatypes (udt) fragments, and includes the Extension Content Datatype (ext) fragment.
The custom defined Extension Content Datatype (ext) fragment is shown to be overwriting the standard fragment of the same name, and that imports the Extension Apex (myext) fragment for the customization.
The Extension Apex imports the Extension Aggregate Components (mycac) and Extension Basic Components (mycbc) fragments.
The Extension Aggregate Components imports the Common Aggregate Components (cac), Common Basic Components (cbc) and Extension Basic Components (mycbc) fragments.
The Extension Basic Components (mycbc) fragment imports the Unqualified Datatypes (udt) fragment.
]
13.3 Sample extended UBL invoice
[> 14.][< 13.2.4][^^][^^^]
13.3.1 Sample extended UBL invoice
[> 13.3.2][> 14.][< 13.2.4][^^][^^^]
Following the deployment strategy for extending an existing document ([Figure 13.6])
[[1] - publd-zip/samp/custext/xsd has a suite of extension schema fragments
[1] - publd-zip/samp/custext/xml has an extended XML instance
[[2] - two extensions, one unexpected "junk" and one expected "my"
]]
[Example 13-2: 01 <Invoice xmlns:cbc="urn:oasis:...:CommonBasicComponents-2"
02 xmlns:cac="urn:oasis:...:CommonAggregateComponents-2"
03 xmlns= "urn:oasis:...:Invoice-2"
04 xmlns:ext="urn:oasis:...:CommonExtensionComponents-2"
05 xmlns:my= "urn:x-company:myExtensions"
06 xmlns:mycac="urn:x-company:myExtensionsAggregateComponents"
07 xmlns:mycbc="urn:x-company:myExtensionsBasicComponents">
08 <ext:UBLExtensions>
09 <ext:UBLExtension>
10 <ext:ExtensionContent>
11 <junk:junk xmlns:junk="abc"/>
12 ...
13 <ext:UBLExtension>
14 <ext:ExtensionContent>
15 <my:start>
16 <mycac:InvoiceLine>
17 <cbc:ID>A</cbc:ID>
18 <mycbc:NewFacetAmount
19 currencyID="GBP">123.45</mycbc:NewFacetAmount>
20 ...
21 </ext:UBLExtensions>
22 <cbc:UBLVersionID>2.0</cbc:UBLVersionID>
23 <cbc:CustomizationID>urn:oasis:...</cbc:CustomizationID>
24 ...
25 <cac:InvoiceLine>
26 <cbc:ID>A</cbc:ID>
27 <cbc:InvoicedQuantity unitCode="KG">100</cbc:InvoicedQuantity>
28 ...
]
Uses the fragmented approach ([Figure 13.4])
[[1] - the UBL standard invoice line is extended with the new <NewFacetAmount> element
[1] - the correlation between the extension portion and the standard portion of the invoice line is made through the matching <ID> element value
]
13.3.2 Replacement extension content data type
[> 13.3.3][> 14.][< 13.3.1][^][^^][^^^]
Following the deployment strategy for extending an existing document ([Figure 13.6])
[[1] - publd-zip/samp/custext/xsd/common/UBL-ExtensionContentDatatype-2.0.xsd is a replacement of the UBL standard UBL-ExtensionContentDatatype-2.0.xsd
]
[Example 13-3: 01 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
02 xmlns="urn:oasis:...:CommonExtensionComponents-2"
03 targetNamespace="urn:oasis:...:CommonExtensionComponents-2"
04 elementFormDefault="qualified"
05 attributeFormDefault="unqualified"
06 xmlns:my="urn:x-company:myExtensions">
07 <xsd:import namespace="urn:x-company:myExtensions"
08 schemaLocation="MyExtensions.xsd"/>
09 <!-- ===== Type Declaration ===== -->
10 <xsd:complexType name="ExtensionContentType">
11 <!--only one element is allowed as the child of the extension point-->
12 <xsd:choice minOccurs="0" maxOccurs="1">
13 <!--allow any customization other than own-->
14 <xsd:group ref="my:other"/>
15 <!--allow own customization-->
16 <xsd:element ref="my:start"/>
17 </xsd:choice>
18 </xsd:complexType>
19 </xsd:schema>
]
13.3.3 Extension apex definition
[> 13.3.4][> 14.][< 13.3.2][^][^^][^^^]
Following the deployment strategy for extending an existing document ([Figure 13.6])
[[1] - publd-zip/samp/custext/xsd/common/MyExtensions.xsd is a specification of the apex of all extensions
[1] - no real equivalent in the UBL structures, but probably closest to a document element
[1] - both standard and extension definitions of ABIE and BBIE constructs are allowed
]
[Example 13-4: 01 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
02 xmlns="urn:x-company:myExtensions"
03 targetNamespace="urn:x-company:myExtensions"
04 xmlns:mycac="urn:x-company:myExtensionsAggregateComponents"
05 xmlns:mycbc="urn:x-company:myExtensionsBasicComponents"
06 xmlns:cac="urn:oasis:...:CommonAggregateComponents-2"
07 xmlns:cbc="urn:oasis:...:CommonBasicComponents-2"
08 elementFormDefault="qualified"
09 attributeFormDefault="unqualified">
10 <xsd:import namespace="urn:x-company:myExtensionsAggregateComponents"
11 schemaLocation="MyAggregates.xsd"/>
12 <xsd:import namespace="urn:x-company:myExtensionsBasicComponents"
13 schemaLocation="MyBasics.xsd"/>
14 <!--define an element in any namespace other than own namespace-->
15 <xsd:group name="other">
16 <xsd:sequence>
17 <xsd:any namespace="##other" processContents="skip"/>
18 </xsd:sequence>
19 </xsd:group>
20 <!--define the apex of own extension-->
21 <xsd:element name="start">
22 <xsd:complexType>
23 <xsd:sequence>
24 <!--any standard or extended construct is allowed here-->
25 <!--at this time only invoice lines are extended-->
26 <xsd:element ref="mycac:InvoiceLine" maxOccurs="unbounded"/>
27 </xsd:sequence>
28 </xsd:complexType>
29 </xsd:element>
30 </xsd:schema>
]
13.3.4 Extended aggregate components definition
[> 13.3.5][> 14.][< 13.3.3][^][^^][^^^]
Following the deployment strategy for extending an existing document ([Figure 13.6])
[[1] - publd-zip/samp/custext/xsd/common/MyAggregates.xsd defines extension ABIE and ASBIE constructs
[1] - may include UBL standard ASBIE and BBIE constructs
]
[Example 13-5: 01 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
02 xmlns="urn:x-company:myExtensionsAggregateComponents"
03 targetNamespace="urn:x-company:myExtensionsAggregateComponents"
04 xmlns:mycbc="urn:x-company:myExtensionsBasicComponents"
05 xmlns:cac="urn:oasis:...:CommonAggregateComponents-2"
06 xmlns:cbc="urn:oasis:...:CommonBasicComponents-2"
07 xmlns:ccts="urn:un:unece:uncefact:documentation:2"
08 elementFormDefault="qualified"
09 attributeFormDefault="unqualified">
10 <xsd:import namespace="urn:x-company:myExtensionsBasicComponents"
11 schemaLocation="MyBasics.xsd"/>
12 <xsd:import namespace="urn:oasis:...:CommonBasicComponents-2"
13 schemaLocation="UBL-CommonBasicComponents-2.0.xsd"/>
14 <xsd:element name="InvoiceLine" type="InvoiceLineExtensionType"/>
15 <xsd:complexType name="InvoiceLineExtensionType">
16 ...
17 <xsd:sequence>
18 <xsd:element ref="cbc:ID" minOccurs="1" maxOccurs="1">
19 ...
20 </xsd:element>
21 <xsd:element ref="mycbc:NewFacetAmount" minOccurs="1" maxOccurs="1">
22 ...
23 </xsd:element>
24 </xsd:sequence>
25 </xsd:complexType>
26 </xsd:schema>
]
13.3.5 Extended basic components definition
[> 14.][< 13.3.4][^][^^][^^^]
Following the deployment strategy for extending an existing document ([Figure 13.6])
[[1] - publd-zip/samp/custext/xsd/common/MyBasics.xsd defines extension BBIE constructs
[1] - every construct should be based on the UN/CEFACT unqualified data types
]
[Example 13-6: 01 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
02 xmlns="urn:x-company:myExtensionsBasicComponents"
03 targetNamespace="urn:x-company:myExtensionsBasicComponents"
04 xmlns:udt="urn:un:...:UnqualifiedDataTypesSchemaModule:2"
05 elementFormDefault="qualified"
06 attributeFormDefault="unqualified">
07 <xsd:import namespace="urn:un:...:UnqualifiedDataTypesSchemaModule:2"
08 schemaLocation="UnqualifiedDataTypeSchemaModule-2.0.xsd"/>
09 <!--define the basic constructs of my extension-->
10 <xsd:element name="NewFacetAmount" type="udt:AmountType"/>
11 </xsd:schema>
]
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.