These pages should be seen as the normative description of the classes described. In case of any conflict, the most specific description will always apply. For example, the description on the lines of a specific element takes precedence of the description at document level. Hence, the descriptions at document level are default values for the lines. The examples in the document and related common guidelines should be seen as descriptive. The guideline text takes precedence of the figures. The actual specification of a class is composed of:

A figure showing the class elements that are included in OIOUBL.
A text specification of the class.
A list of the fields that are included in the class with a corresponding table of key data such as definitions, names, references, and business rules for each of the class fields.
A list of the sub-classes that are included in the class with a corresponding table of key data such as definitions, names, references, and business rules for the sub-classes of the class.
An example of the class
A list of the UBL elements that from a business perspective make no sense in the specific context.

Figure definitions

In the class specifications, the class is shown as schema documentation. Figure Description

Term definitions

In this specification, the following terms will be used in the tables:

Term	Explanation
UBL name	The name that is found in the UBL 2.0 schemas
DK-name	The name in Danish
Use	Describes the cardinality, i.e. the rule describing how may instances of the business information entity are allowed: [1] specifies that one and only one instance is allowed. [0..1] means that the business information entity is optional. [0..n] means that null to infinity instances may occur. [1..n] means that no less than one instance to an infinite number of instances may occur.
Alternative term	Specifies a term which is also used to describe the business information entity.
Used	Determines whether the receiver should be expected to be able to decode the described business information, if it is attached. Information that is not used may still, however, be used upon bilateral agreement.
Business rule	Describes the rules that are attached to the business information entity. Business rules are normative, and will be part of the validation of the document in question.
Recommended	Specifies that common practice requires the described business information entity to be attached. This is a non-normative guide to the use of the business information entity.
Allowed values:	Describes the value set that the business information entity should conform with.
Codelist	Refers to the codelist that the value set should be found in.
Class	A structure of coherent business information.

How to fill in OIOUBL document instances

An XML document must follow the related UBL schema, and conform to the rules of this guideline. The instances follow the W3C XML specifications, which means that, unless otherwise stated, the normal XML rules rules apply. It is therefore recommended that an xml encoder is used for reading the documents.

Namespace

A Namespace is a semantic space in which names are unique and attached to a specific interpretation. Namespaces often occur as libraries, and may be referenced via an alias-variable. The expression: <… xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" …> means that elements with the prefix "cac" (alias variable) belongs to the "…CommomAggregateComponents-2" namespace. The namespace that is referenced by the actual document is indicated by "xmlns =...", i.e. without an alias variable. It is recommended to use the alias variables that are specified in UBL, but this is not a requirement. For an OIOUBL document instance to be validated the following namespaces must be specified:

Alias variable	Namespace
	The target namespace of the document in question
cac	urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2
ccts	urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters-2
cbc	urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2
sdt	urn:oasis:names:specification:ubl:schema:xsd:SpecializedDatatypes-2
udt	urn:un:unece:uncefact:data:specification:UnqualifiedDataTypesSchemaModule:2
ext	urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2
xsi	http://www.w3.org/2001/XMLSchema-instance

Comments

Comments may be used in document instances to facilitate any manual processing of the document. This is particularly relevant during the introduction phase of new systems that use OIOUBL. For those who wish to formalize these comments, we recommend the Dublin-Core metadata definitions, see "http://dublincore.org/documents/dcmi-terms/". The following terms are used in the examples of the scenario descriptions [S01-S07] :

DC-Term	Description	Example
Title	Describes the title of the document instance	BASPRO_01_01_00_Invoice_v2p0.xml
Replaces	Reference to the preceding instance	BASPRO_01_01_00_Invoice_v0p1.xml
Publisher	Describes who is responsible for the document instance.	"IT og Telestyrelsen"
Creator	Describes the person or the system that created the instance.	"OIOERP v 1.0.2 release 34"
Created	Date (and possibly time) of the creation of the document.	2006-09-08
Modified	Date (and possibly time) when the document was last modified.	2006-09-08
Issued	Date (and possibly time) when it was issued.	2006-09-08
ConformsTo	Description of the context that it belongs to.	OIOUBL_ScenarioPackage_BASPRO
Description	General description	"This document is produced as part of the OIOUBL Basic procurement scenario package"
Rights	Any copyrights that apply to the instance.	"It can be used following the Common Creative License"

Only use meta data that you consider applicable, and only enter valid data. From the above list we particularly recommend using the "Creator" term, as this may ease the troubleshooting at the receiver's system. Comments should be specified within the root element of the document.

Process instructions

Process instructions are instructions that are not covered by the OIOUBL standard, but which may be used for controlling other logics. For example, when specifying that an instance is used for test purposes. A process instruction is specified by "<?name ... ?>" and may contain attributes as shown in the example below. Process instructions should be specified within the root element of the document.
<?TestInstance
ResponseTo="smtp:test@company.dk"
description= "apply your comment here"
?>

Relations to instances of other customizations

An instance is specified as being OIOUBL by entering ”CustomizationID” as ”OIOUBL-2.0”. OIOUBL instances are built upon UBL 2.0, and may therefore be interpreted directly by UBL 2.0 readers. Instances from other UBL 2.0-customizations can be read directly by OIOUBL readers by changing the "CustomizationID", provided the instance conforms to the requirements of this guideline.

Code example

Code examples are available in the scenario descriptions [S01-S07]