text:
15 September 2004
This document is an OASIS Committee Draft.
Bill Meadows <email@example.com>
Lisa Seaburg, Aeon LLC <email@example.com>
Members of the Technical Committee
This specification defines the Universal Business Language.
This document is a Committee Draft of the OASIS Universal Business Language (UBL) Technical Committee. The OASIS UBL Technical Committee invites interested parties to comment on this release using the comment link on the UBL TC web page:
1 Introduction
2 Normative References
3 Terms and Definitions
4 Symbols and Abbreviations
5 UBL 1.0 Procurement Process
6 UBL 1.0 Schemas
Appendix A (Informative): Release Notes
Appendix B (Informative): UBL Methodology
Appendix C (Informative): Formatting Specifications
Appendix D (Informative): Example Instances
Appendix E (Informative): Code Lists
Appendix F (Informative): ASN.1 Specification
Appendix G (Informative): Ongoing Work Items
Appendix H: Notices
Since its approval as a W3C recommendation in 1998, XML has been adopted in a number of industries as a framework for the definition of the messages exchanged in electronic commerce. The widespread use of XML has led to the development of multiple industry-specific XML versions of such basic documents as purchase orders, shipping notices, and invoices.
While industry-specific data formats have the advantage of maximal optimization for their business context, the existence of different formats to accomplish the same purpose in different business domains is attended by a number of significant disadvantages as well.
Developing and maintaining multiple versions of common business documents like purchase orders and invoices is a major duplication of effort.
Creating and maintaining multiple adapters to enable trading relationships across domain boundaries is an even greater effort.
The existence of multiple XML formats makes it much harder to integrate XML business messages with back-office systems.
The need to support an arbitrary number of XML formats makes tools more expensive and trained workers harder to find.
The OASIS Universal Business Language (UBL) is intended to help solve these problems by defining a generic XML interchange format for business documents that can be extended to meet the requirements of particular industries. Specifically, UBL 1.0 provides the following:
A library of XML schemas for reusable data components such as "Address," "Item," and "Payment" — the common data elements of everyday business documents.
A small set of XML schemas for common business documents such as "Order," "Despatch Advice," and "Invoice" that are constructed from the UBL library components and can be used in a generic order-to-invoice trading context.
Support for the customization of UBL in specific trading relationships.
A standard basis for XML business schemas is expected to have the following advantages:
Lower cost of integration, both among and within enterprises, through the reuse of common data structures.
Lower cost of commercial software, because software written to process a given XML tag set is much easier to develop than software that can handle an unlimited number of tag sets.
An easier learning curve, because users need master just a single library.
Lower cost of entry and therefore quicker adoption by small and medium-size enterprises (SMEs).
Standardized training, resulting in many skilled workers.
A universally available pool of system integrators.
Standardized, inexpensive data input and output tools.
UBL is designed to provide a universally understood and recognized commercial syntax for legally binding business documents and to operate within a standard business framework such as ISO 15000 (ebXML) to provide a complete, standards-based infrastructure that can extend the benefits of existing EDI systems to businesses of all sizes. UBL is freely available to everyone without legal encumbrance or licensing fees.
UBL schemas are modular, reusable, and extensible in XML-aware ways. Designed as an implementation of ebXML Core Components Technical Specification 2.01, the UBL Library is based on a conceptual model of information components known as Business Information Entities (BIEs). These components are assembled into specific document models such as Order and Invoice. These document assembly models are then transformed in accordance with UBL Naming and Design Rules into W3C XSD schema syntax. This approach facilitates the creation of UBL-based document types beyond those specified in this 1.0 release. This document describes the basic order-to-invoice business process that the UBL document types are designed to support.
To aid in deployment, the standard UBL schemas are accompanied by a multitude of informative supporting materials, some of which are included in this package as informative appendices and some of which are available from referenced sites. These materials include:
UML class diagrams of the document components on which the schemas are based
UML class diagrams describing all the document assemblies
Spreadsheet models defining the document assemblies
Descriptions of two example implementations
Sample instances of each of the UBL documents used in those two implementations
Formatting specifications for rendering all of the documents in the example use cases
Formatting specifications for the United Nations Layout Keys corresponding to each of the UBL basic business document types
An ASN.1 specification to enable the transmission of UBL messages in binary form
The terms Core Component (CC), Basic Core Component (BCC), Aggregate Core Component (ACC), Association Core Component (ASCC), Business Information Entity (BIE), Basic Business Information Entity (BBIE), and Aggregate Business Information Entity (ABIE) are used in this specification with the meanings given in [CCTS].
The terms Object Class, Property Term, Representation Term, and Qualifier are used in this specification with the meanings given in [ISO11179].
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
The UBL 1.0 documents and component library are designed to support a typical order-to-invoice procurement cycle. This section describes the business rules and choreography of the generic process and the role played by each of the UBL 1.0 document types in that process.
It is important to note that the UBL library is designed to support the construction of a wide variety of document types beyond those provided in the 1.0 package. It is expected that other document types will be added as UBL evolves.
This model describes a basic trading cycle from Order to Invoice that involves three parties: a Buyer of goods, a Seller of goods, and a Recipient of goods, who may or may not be the Buyer. The document types provided by UBL to support this process include the following:
Order Response Simple
Order Response (detailed)
Order Change
Order Cancellation
Despatch Advice
Receipt Advice
The bold boxes in the diagram below show the role of each document type in the generic process.
Figure 1. Order-to-Invoice Business Process
This section describes the business rules of the generic order-to-invoice process that are assumed as information requirements for the document types in UBL 1.0.
The Order may specify allowance and charge instructions (e.g. freight, documentation, etc.) that identify the type of charge and who pays which charges. The Order can be placed "on account" against a trading credit account held by the Seller, or against a credit/debit card account, or a direct debit agreement. The Order allows for an overall currency defining a default for all pricing and also a specific currency to be used for Invoicing. Within an Order, additional currencies can be specified both for individual item pricing and for any allowances or charges.
Trade discount may be specified at the Order level. The Buyer may not know the trade discount, in which case it is not specified. This makes a detailed response from the Seller necessary; see Order Response (5.2.3).
The Order may specify delivery terms and constraints that apply for the delivery location in relation to the following information that would normally not appear until the Despatch Advice:
One- to many-legged shipment stages
Arrival "window"
Consignment packaging
Type, e.g. Container, Pallet
Identifier, e.g. SSCC, Shipping label (Despatch Advice)
The Order provides for multiple Order Lines. Each Order Line provides for specification of a single place of delivery, and a schedule of quantities and requested delivery dates.
The Order may specify delivery terms, while the Order Line may provide instructions for delivery.
The Buyer may indicate potential alternatives that are acceptable. For each Order Line, an Alternative Item can be included. The Alternative Item may be specified by any one of the range of Item identifiers. For example, the specified Quantity may change, e.g. 20x6-packs as an alternative to 10x12-packs.
The Order Response Simple is the means by which the Seller confirms receipt of the Order from the Buyer, indicating either commitment to fulfill without change or that the Order has been rejected.
Proposed changes by the Seller are accomplished through the full Order Response document.
The Order Response proposes to replace the original Order. It reflects the entire new state of an order transaction. It also is the means by which the Seller confirms or supplies Order-related details to the Buyer that were not available to, or specified by, the Buyer at the time of ordering. These may include:
Delivery date, offered by the Seller if not specifically requested by the Buyer
Trade Discount
Customs Commodity Classification codes
The Seller may advise replacements or substitutes which will be made, or changes necessary, using the Order Response. The Substitute or Replacement Item may be specified by any one of the range of Item identifiers. For example, the specified Quantity may change, e.g. 20x6-packs as a replacement for 10x12-packs.
The Buyer can change an established Order in two ways, subject to the legal contract or trading partner agreement: first, by sending an Order Change, or second, by sending an Order Cancellation (see 5.2.5) followed by a new, complete replacement Order.
An Order Change reflects the entire current state of an order transaction.
Buyers can initiate a change to a previously accepted order for various reasons, such as changing ordered items, quantity, delivery date, ship-to address, etc. Suppliers can accept or reject the Order Change using either Order Response or Order Response Simple.
At any point of the process, a Buyer can cancel an established order transaction using the Order Cancellation document. Legal contracts, trading partner agreements, and business rules will restrict at what point an Order Cancellation will be ignored (e.g. at the point of manufacture or delivery process initiation). Given the agreements and rules, an Order Cancellation may or may not be an automated business transaction. The terms and conditions of contract formation for business commitments will dictate which, if any, of these restrictions or guidelines will apply.
The following information may appear in the Despatch Advice:
One- to many-legged shipment stages
Arrival "window"
Consignment packaging
Type, e.g. Container, Pallet
Identifier, e.g. SSCC, Shipping label (DespatchAdvice)
The Despatch Advice provides for two situations:
Organization of the delivery set of items by Transport Handling Unit(s) so that the Receiver can check the Transport Handling Unit and then contained items. Quantities of the same item on the same Order Line may be separated into different Transport Handling Units, and hence appear on separate Despatch Lines within a Transport Handling Unit.
Organization of the delivery set of items by Despatch Line, annotated by the Transport Handling Unit in which they are placed, to facilitate checking against the Order. For convenience, any Order Line split over multiple Transport Handling Units will result in a Despatch Line for each Transport Handling Unit they are contained in.
Additionally, in either case, the Despatch Advice can advise:
Full Despatch — advising the Recipient and/or Buyer that all the items on the order will be, or are being, delivered in one complete consignment on a given date.
Partial Despatch — advising the Recipient and/or Buyer that the items on the order will be, or are being, partially delivered in a consignment on a given date.
Despatch Lines of the Despatch Advice need not correspond one-to-one with Order Lines, and are linked by a reference. The information structure of the Despatch Advice may result in multiple Despatch Lines from one Order Line. Equally, partial despatch may result in some Order Lines not being matched by any Line in a Despatch Advice.
Within a Despatch Advice, an Item may also indicate the Country of Origin and the Hazardous nature of the Item.
The Receipt Advice is sent by the Receiver (Buyer) to the Seller to confirm receipt of items and is capable of reporting shortages or damaged items.
The Receipt Advice provides for two situations. For ease of processing claimed receipt against claimed delivery, it must be organised in the same way as the corresponding Despatch Advice:
Indication of receipt by Transport Handling Unit(s) and contained Receipt Lines one-to-one with the Despatch Advice as detailed by the Seller party.
Indication of receipt by Receipt Lines annotated by Transport Handling Unit, one-to-one with the Despatch Advice as detailed by the Seller party.
The Receipt Advice allows the Receiver to state any shortages from the claimed despatch quantity and to state any quantities rejected for a given reason.
As presently arranged, the Receipt Line allows for one rejection quantity and reason. However, additional reasons for rejection of quantities of the same item could be achieved by subdividing the Receipt Line so that there are multiple Receipt Lines to one Despatch Line.
The Invoice is normally issued on the basis of one despatch event triggering one invoice. An Invoice may also be issued for pre-payment on a whole or partial basis. The possibilities are:
Prepayment invoice (payment expected)
Pro-forma invoice (pre advice, payment not expected)
Normal Invoice, on despatch for despatched items
Invoice after return of ReceiptAdvice
The Invoice only contains the information that is necessary for invoicing purposes. It does not reiterate any information already established in the Order, Order Change, Order Response, Despatch Advice, or Receipt Advice that is not necessary when invoicing. If necessary, the Invoice refers to the Order, Despatch Advice or Receipt Advice by a Reference for those documents.
Taxation on the Invoice allows for compound taxes, the sequence of calculation being implied by the sequence of information repeated in the data stream (e.g., Energy tax, with VAT — Value Added Tax — superimposed).
Charges can be specified either as a lump sum or by percentage applied to the whole Invoice value prior to calculation of taxes. Such charges cover:
Each Invoice Line refers to any related Order Line(s) and may also refer to the Despatch Line and/or Receipt Line.
The Invoice does not cover Debit and Credit Notes, nor does the process include a Customer Account Statement that summarises Invoices, Credit Notes, and Debit Notes to be paid.
Item structures are found throughout the document types in the generic process.
An Identifier identifies each Item (e.g. a product identifier), which shall be one of the following:
Buyer's Item Identification, or
Seller's Item Identification, or
Manufacturer's Item Identification, or
Catalogue Item Identification, or
Item Identification according to a system promulgated by a standards body.
The Item Identification assumes that each different packaging of an Item (e.g. a 6-pack and a 12-pack of the same item) has a different Item Identifier.
The Item may be further distinguished by the specification of Measurement(s) or Physical Attribute(s). This enables specification of the following kinds of item:
This is an item that is not identified by an unambiguous machine-processable product code and requires additional descriptive information to precisely identify it.
This is an item that the customer describes according to his need, and in the specification of which the customer may make some reference to comparable "standard" items.
This is an item for which it is necessary to specify one or more measurements as part of the descriptive specification of the item.
For any given Item, price ranges by amount, quantity, etc. are not repeated back to the Seller; only the active price is specified. The Buyer may not know the Item Base Price, in which case it is not specified. This makes a detailed response from the Seller necessary; see OrderResponse.
Although ordered items may include Hazardous items, as it is not necessary to specify related information at the order stage. The Buyer may not be aware of the nature of the Item. Indication of the Hazardous nature of the Item, and any relevant information, would be indicated in the Despatch Advice.
The UBL XSD schemas are implementations of the document assembly models defined by UBL. They are the only normative representation of the UBL 1.0 document types and library components.
All of the UBL 1.0 XSD schemas are contained in the
subdirectory of the UBL 1.0 release package (see Appendix A for more
information regarding the structure of the 1.0 release package and Section 6.4
for information regarding dependencies among the schema modules). The
xsd/ directory is further subdivided into
xsd/common/, and
xsd/codelist/ subdirectories.
For convenience in implementing the schemas, a parallel (and
technically non-normative) "runtime" set with
the annotation elements stripped out is provided in
xsdrt/ directory.
The XSD schemas defining the eight basic document types that support the
generic UBL 1.0 order-to-invoice process are located in the
xsd/maindoc/ directory, as listed below.
- Order
- xsd/maindoc/UBL-Order-1.0.xsd
- Order Response
- xsd/maindoc/UBL-OrderResponse-1.0.xsd
- Order Response Simple
- xsd/maindoc/UBL-OrderResponseSimple-1.0.xsd
- Order Change
- xsd/maindoc/UBL-OrderChange-1.0.xsd
- Order Cancellation
- xsd/maindoc/UBL-OrderCancellation-1.0.xsd
- Despatch Advice
- xsd/maindoc/UBL-DespatchAdvice-1.0.xsd
- Receipt Advice
- xsd/maindoc/UBL-ReceiptAdvice-1.0.xsd
- Invoice
- xsd/maindoc/UBL-Invoice-1.0.xsd
xsd/common directory contains six schemas
referenced by the eight document schemas in
xsd/maindoc. Two of these common schemas
contain the UBL library of reusable data components from
which the main document schemas are assembled; three
contain definitions needed to implement [CCTS] conformance; and one provides a
consistent format for schema metadata. The name of each
schema file together with a brief description of its
contents is given below.
- Common Basic Components
- xsd/common/UBL-CommonBasicComponents-1.0.xsd
- This schema defines the global Basic Business Information Entities (BBIEs) that are used throughout UBL, serving, in effect, as a "global BBIE type database" for constructing documents. As specified by the UBL Naming and Design Rules, this schema does not include BBIEs having Code or Identifier datatypes; these are defined locally wherever they are used.
- Common Aggregate Components
- xsd/common/UBL-CommonAggregateComponents-1.0.xsd
- This schema defines the Aggregate Business Information Entities (ABIEs) that are used throughout UBL, serving, in effect, as an "ABIE type database" for constructing the main documents.
- Core Component Types
- xsd/common/UBL-CoreComponentTypes-1.0.xsd
- This schema provides Core Component Types as defined by [CCTS]. These types are used to construct higher-level datatypes in a standardized and consistent manner. This schema should not be modified.
- Unspecialized Datatypes
- xsd/common/UBL-UnspecializedDatatypes-1.0.xsd
- This schema defines Unqualified Data Types for primary and secondary representation terms as specified by [CCTS]. Derived from Core Component Types, these XSD complexType structures are the basic data types from which all other data types must derive. This schema should not be modified.
- Specialized Datatypes
- xsd/common/UBL-SpecializedDatatypes-1.0.xsd
- This schema provides Qualified Data Types as defined by [CCTS]. These XSD complexType structures are derived from Unspecialized Datatypes by extension, restriction, and other contextual constraints, such as facets. The Specialized Datatypes have been customized for the UBL 1.0 procurement process and may be further extended to support additional datatypes required for other business contexts.
NOTE: The terms "specialized" and "unspecialized" are used instead of the terms "qualified" and "unqualified" in order to avoid confusion with qualified and unqualified names in [XSD1][XSD2].
- Core Component Parameters
- xsd/common/UBL-CoreComponentParameters-1.0.xsd
- This schema defines the structure of the annotation/documentation sections that appear in all the other schemas, providing a consistent format for metadata such as object class, representation terms, semantic descriptions, and other supplementary information.
The thirteen code list schemas required for UBL 1.0 are included in the
xsd/codelist directory. These code list
schemas allow component instances conformant to any of
the main document schemas to be validated against code
list values. See Appendix E for further information about
the form of representation used for UBL code lists.
- Acknowledgement Response Code
- xsd/codelist/UBL-CodeList-AcknowledgementResponseCode-1.0.xsd
- Allowance Charge Reason Code
- xsd/codelist/UBL-CodeList-AllowanceChargeReasonCode-1.0.xsd
- Channel Code
- xsd/codelist/UBL-CodeList-ChannelCode-1.0.xsd
- Chip Code
- xsd/codelist/UBL-CodeList-ChipCode-1.0.xsd
- Country Identification Code
- xsd/codelist/UBL-CodeList-CountryIdentificationCode-1.0.xsd
- Currency Code
- xsd/codelist/UBL-CodeList-CurrencyCode-1.0.xsd
- Document Status Code
- xsd/codelist/UBL-CodeList-DocumentStatusCode-1.0.xsd
- Latitude Direction Code
- xsd/codelist/UBL-CodeList-LatitudeDirectionCode-1.0.xsd
- Line Status Code
- xsd/codelist/UBL-CodeList-LineStatusCode-1.0.xsd
- Longitude Direction Code
- xsd/codelist/UBL-CodeList-LongitudeDirectionCode-1.0.xsd
- Operator Code
- xsd/codelist/UBL-CodeList-OperatorCode-1.0.xsd
- Payment Means Code
- xsd/codelist/UBL-CodeList-PaymentMeansCode-1.0.xsd
- Substitution Status Code
- xsd/codelist/UBL-CodeList-SubstitutionStatusCode-1.0.xsd
The following diagram shows the dependencies among the schema modules comprising a UBL 1.0 document schema. Note that (as in the other UML diagrams used in this release) dependent components point to the components upon which they depend.
Figure 2. UBL Schema Dependencies
Online and downloadable versions of this release are available from the locations specified at the top of this document.
The UBL 1.0 specification is published as a zip archive named cd-UBL-1.0.zip. Unzipping this archive creates a directory named cd-UBL-1.0 containing a master hypertext document (this document, index.html) and a number of subdirectories. The files in these subdirectories, linked to from index.html, contain the various normative and informational pieces of the 1.0 release. A description of each subdirectory is given below.
- Diagrams and illustrations used in this specification
- ASN.1 specification; see Appendix F
- Supporting documents created by the UBL TC and referenced in this specification
- Formatting specifications; see Appendix C
- UBL spreadsheet models; see Appendix B.3
- UML diagrams; see Appendices B.2, B.3, and B.6
- Example instances; see Appendix D
- XSD schemas; see Section 6
- "Runtime" XSD schemas; see Section 6
UBL has inspired the creation of both free and commercial UBL tools. A list of tools currently available for UBL can be found on the web page of the UBL Software Subcommittee:
UBL is a volunteer project of the international business community. Inquiries regarding UBL may be posted to the public ubl-dev list, archives for which are located at
Subscriptions to ubl-dev can be made through the OASIS list manager at
Certain components in the library allow recursive nesting. For example, a Package may contain other Packages, a Delivery may specify another Delivery, etc. These are legitimate business data structures. Most real-world applications will limit the depth of recursion in such structures, but XSD schemas are incapable of expressing this constraint. Implementors should be aware of this and may wish to set limits on the depth of recursive structures in their applications.
UBL does not mandate the use of a specific formal development method. The purpose of this section is to describe the process that evolved during the development of UBL so that implementers can understand the role of the various technical artifacts included in this package. They may also choose to adapt this approach to suit their requirements.
The approach used to develop UBL 1.0 is shown in the diagram below.
Figure B-1. The UBL Development Process
The initial UBL library of data components was based upon the xCBL 3.0 schema library, which was itself based on the UN/EDIFACT and ANSI X12 EDI component libraries. Upon review, it was felt necessary to create an abstracted conceptual model of the entities in a form that would better support an iterative development lifecycle.
UBL uses two types of conceptual models, a single model for defining information components and a set of models for describing how these components are assembled into document definitions. The former is referred to as the document component model and is generally presented using UML class diagrams (see B.2 below); the latter are referred to as the document assembly models and are generally presented using spreadsheets.
The identification and assembly of the components required by the UBL 1.0 Procurement Process was carried out manually using business knowledge of the domain, the component model, and the requirements of [CCTS]. Individual spreadsheets were developed for each document type in the UBL 1.0 procurement scenario, and all re-used components were combined into a separate spreadsheet. Additional spreadsheets were used to model the Core Component Types (CCTs), Unspecialized Datatypes (UDTs), and Specialized Datatypes (SDTs) as specified by [CCTS]. The full set of spreadsheet assembly models used by UBL 1.0 is described in Section B.3.
The UBL schemas contained in Section 6 of this specification were then generated automatically from the spreadsheet assembly models following the UBL Naming and Design Rules referenced in Section B.4 according to the process described in Section B.5. Implementation models were then generated from the schemas to serve as an aid in implementing UBL. These UML class diagrams, provided in Section B.6, represent the implementation of the document assembly models described in the spreadsheets.
The UBL document component model describes the information components used in all of the documents defined by UBL 1.0.
The document component model is the result of a detailed analysis of the data requirements to support the UBL 1.0 Procurement Process (see Section 5). During the modeling process, common items of data were identified by a process of normalization to identify aggregates based on functional dependency. Where appropriate, these were generalized so that they could be re-used to support the various business documents.
The document component model is used for the following purposes:
It facilitates the identification of the reusable components — i.e., the data structures that are common across the UBL 1.0 business documents
It aids in understanding the information requirements of the total scenario
It is the source from which the BIEs are derived and documented in the UBL document assembly models
The component model is best viewed as a series of UML Class Diagrams. For legibility, the model does not contain all the metadata required for document assembly.
Figure B-2 shows the overall UBL document component model.
To facilitate comprehension of this diagram, it has been decomposed into several packages. Each package represents a logical grouping of components and is described by its own UML class diagram, which displays both the attributes (Basic BIEs) and object classes (Aggregate BIEs) belonging to the components grouped in the package. The scope of each package is arbitrary and does not hold any significance beyond these diagrams.
For example, the Party reusable component package is shown below.
Figure B-3. Party Component Package
The complete set of packages for all the UBL components is listed below.
- Address Package
- uml/concept/comp/UBL-1.0-AddressPackage.jpg
- Contract Package
- uml/concept/comp/UBL-1.0-ContractPackage.jpg
- Delivery Package
- uml/concept/comp/UBL-1.0-DeliveryPackage.jpg
- Document Reference Package
- uml/concept/comp/UBL-1.0-DocumentReferencePackage.jpg
- Hazardous Item Package
- uml/concept/comp/UBL-1.0-HazardousItemPackage.jpg
- Item Package
- uml/concept/comp/UBL-1.0-ItemPackage.jpg
- Party Package
- uml/concept/comp/UBL-1.0-PartyPackage.jpg
- Payment Package
- uml/concept/comp/UBL-1.0-PaymentPackage.jpg
- Procurement Package
- uml/concept/comp/UBL-1.0-ProcurementPackage.jpg
- Tax Package
- uml/concept/comp/UBL-1.0-TaxPackage.jpg
No specific directions are defined for the associations in these models; they can be navigated in either direction. The specific navigation path for each association is defined when documents are assembled.
To define different types of documents, the components described in the previous section are assembled into hierarachical structures based on the requirements of the context — in this case the UBL 1.0 Procurement Process — and the metadata requirements of [CCTS].
Document assembly starts with the definition of each of the business documents comprising UBL 1.0 as an Aggregate BIE (object class) for the document type. All the other Aggregate BIEs (object classes) for the document type are derived by traversing the associations from this Aggregate BIE to form the required hierarchy. The roles chosen for each association between Aggregate BIEs become Association BIEs.
For example, the document assembly model for the top level of the UBL 1.0 Order document is shown below using a UML class diagram.
Figure B-4. Order Document Assembly Model
The top level document assembly models for the eight business documents defined by UBL 1.0 are given below.
- Order assembly model
- uml/concept/assy/UBL-1.0-OrderDocumentAssembly.jpg
- Order Response assembly model
- uml/concept/assy/UBL-1.0-OrderResponseDocumentAssembly.jpg
- Order Response Simple assembly model
- uml/concept/assy/UBL-1.0-OrderResponseSimpleDocumentAssembly.jpg
- Order Change assembly model
- uml/concept/assy/UBL-1.0-OrderChangeDocumentAssembly.jpg
- Order Cancellation assembly model
- uml/concept/assy/UBL-1.0-OrderCancellationDocumentAssembly.jpg
- Despatch Advice assembly model
- uml/concept/assy/UBL-1.0-DespatchAdviceDocumentAssembly.jpg
- Receipt Advice assembly model
- uml/concept/assy/UBL-1.0-ReceiptAdviceDocumentAssembly.jpg
- Invoice assembly model
- uml/concept/assy/UBL-1.0-InvoiceDocumentAssembly.jpg
While it is possible to develop document assembly models using UML, it was found easier in practice to use a spreadsheet notation, the key advantages being:
The additional metadata required by [CCTS] is easily defined
Formulas can be applied to naming rules
Spreadsheets can be mapped directly to the submission format for candidate Core Components required byUN/CEFACT TBG17
Spreadsheets are familiar to the business experts responsible for the data modeling
The format has proven portable between applications
These advantages were felt to outweigh the main disadvantage of spreadsheet notation, which is the lack of referential integrity controls in the modeling language itself; manual editing is required to control the impact of changes. In this case, fortunately, the commercial tool used to generate the final schemas from the spreadsheets was also capable of verifying model integrity.
UBL uses spreadsheets to describe the assembly of components into specific types of documents. There is one spreadsheet assembly model for each document type.
Following the terminology of [CCTS], the document assembly models are composed of a combination of Basic Business Information Entities (the attributes of the component model), Aggregate Business Information Entities (the object classes of the component model), and Association Business Information Entities (the roles of associations in the component model). BBIEs can be considered the "leaf nodes" of the data structures, ABIEs as structures that contain BBIEs, and ASBIEs as the containership of one ABIE within another.
The spreadsheet models use rows to define components. Components are either BIEs or Data Types. Columns define the metadata associated with each component type. Many of the spreadsheet columns are determined by [CCTS] requirements.
A spreadsheet assembly model will therefore consist of a "root" ABIE, a set of BBIEs, and a set of ASBIEs. The ABIEs associated with the "root" ABIE are defined in a Reusable BIE spreadsheet model.
The data types for all BBIEs are defined either in the Unspecialized Datatypes spreadsheet model or the Specialized Datatypes spreadsheet model.
The dependencies among these spreadsheet assembly models are shown in the diagram below.
Figure B-5. Spreadsheet Model Dependencies
The spreadsheet files included in this package are provided in both Microsoft Excel format (.xls) and Open Office format (.sxc) as described below.
NOTE: The UBL document schemas are automatically generated from these spreadsheet models. However, the normative forms of the UBL documents are not these spreadsheet models but the XSD schemas themselves, which are provided in Section 6.
Each business information entity (BIE) is defined in a single row. Row background colour distinguishes between BBIE (white), ABIE (pink), and ASBIE (green).
- Order document spreadsheet
- mod/maindoc/UBL-Order-1.0.sxc
- mod/maindoc/UBL-Order-1.0.xls
- Order Response document spreadsheet
- mod/maindoc/UBL-OrderResponse-1.0.sxc
- mod/maindoc/UBL-OrderResponse-1.0.xls
- Order Response Simple document spreadsheet
- mod/maindoc/UBL-OrderResponseSimple-1.0.sxc
- mod/maindoc/UBL-OrderResponseSimple-1.0.xls
- Order Change document spreadsheet
- mod/maindoc/UBL-OrderChange-1.0.sxc
- mod/maindoc/UBL-OrderChange-1.0.xls
- Order Cancellation document spreadsheet
- mod/maindoc/UBL-OrderCancellation-1.0.sxc
- mod/maindoc/UBL-OrderCancellation-1.0.xls
- Despatch Advice document spreadsheet
- mod/maindoc/UBL-DespatchAdvice-1.0.sxc
- mod/maindoc/UBL-DespatchAdvice-1.0.xls
- Receipt Advice document spreadsheet
- mod/maindoc/UBL-ReceiptAdvice-1.0.sxc
- mod/maindoc/UBL-ReceiptAdvice-1.0.xls
- Invoice document spreadsheet
- mod/maindoc/UBL-Invoice-1.0.sxc
- mod/maindoc/UBL-Invoice-1.0.xls
While those wishing to customize UBL should follow the guidelines for the customization of UBL 1.0 schemas referenced from B.7 below, those who choose to modify either the Component or Assembly models directly and use UBL as the basis for a new vocabulary should be aware of the following considerations that may impact compatibility with UBL:
First, any modification of the spreadsheet models requires an understanding of their structure, the ebXML Core Components Technical Specification [CCTS], and the various UBL library constituents. For example, some columns are updated directly, while others have formulas in their cells which implement [CCTS] and UBL Naming and Design Rules. Awareness of this is necessary when adding or editing the row contents. Care should be taken to avoid updating cells that contain formulas.
Second, schema generation should be compliant with the UBL Naming and Design Rules (B.4 below) to promote compatibility with other UBL component libraries.
Third, the data types defined in the Core Component Types and Unspecialized Datatypes models are direct implementations of those defined in [CCTS] and should not be modified without recognition of this fact. The Specialized Data Types model is provided for implementation-specific data types.
The UBL 1.0 document component and document assembly models are the product of the OASIS UBL Library Content Subcommittee. The work of the UBL LCSC can be viewed on the LCSC web page:
The UBL XML Naming and Design Rules (NDR) checklist included in this package describes the rules used to determine UBL 1.0 XSD schema structures and element/attribute names. The NDR checklist can be found in this package as the following file:
The UBL Naming and Design Rules are the product of the OASIS UBL NDR Subcommittee. The work of the UBL NDRSC can be viewed on the NDRSC web page:
The UBL 1.0 XSD schemas are the output of a transformation that applies schema construction rules to the Data Model represented by the UBL spreadsheets described in B.3 above. The transformation process consisted of the following steps:
A commercial CC-aware schema generation tool, GEFEG EDIFIX® 5.0, was used to read the spreadsheets as UML data models, perform Q/A with them, and produce a schema representation adhering to the UBL 1.0 Naming and Design Rules, as illustrated below. For information regarding GEFEG EDIFIX®, see http://www.gefeg.com/en/standard/xml/ubl.htm. The GEFEG EDIFIX® 5.0 UBL Reader is free and offers easy viewing of UBL schemas and data models. For information regarding GEFEG EDIFIX® UBL Reader, see http://www.gefeg.com/en/edifix/reader-ubl.html.
Figure B-6. UBL Schema Generation Process
Previous drafts of the UBL specification used different tools for this process. For a description of the process used to produce the UBL 1.0 Beta schemas, see Appendix D of the 1.0 Beta Committee Draft at http://www.oasis-open.org/committees/ubl/lcsc/UBLv1-beta/.
UBL 1.0 schema generation was performed under the direction of the OASIS UBL Tools and Techniques Subcommittee. The work of the UBL TTSC can be viewed on the TTSC web page:
The implementation model of UBL represents the actual UBL XSD schemas as a UML model. This is produced by automatically transforming the schemas into a model conformant with the Unified Modeling Language [UML]. This model is then used to produce a set of class diagrams that illustrate each of the main documents and several views of the reusable components. The automated transformation and diagram creation was performed using a commercial schema-to-UML transformation tool, Ontogenics hyperModel. For further details regarding this product, see http://www.xmlmodeling.com/.
The UML class diagrams contained in this section are intended to help understand the UBL schemas without requiring an understanding of XSD syntax. In order to do this, the diagrams intentionally suppress some of the detail contained in the schemas. For example, information regarding the order of elements within a complex type definition is not preserved in the diagrams. Other changes were made to make the UML model useful for software engineering; for example, the "Type" suffixes of XSD complexType names are removed when creating the UML class name to yield an object class name independent of XSD syntax, and complex type child elements with simple content values are represented as class attributes, whereas elements with complex content are represented as associations to those type classes.
These diagrams are the UML equivalent of the document assembly spreadsheet models.
An implementation class diagram has been created for each of the eight UBL 1.0 document types. As noted above, the implementation diagrams are simplified views that suppress details of the types contained in these aggregate structures. As an example, the class diagram for the UBL Order document is shown in the figure below.
Figure B-7. Implementation Model for the Order Document
The document implementation class diagrams contained in the UBL 1.0 package are listed below.
- Order implementation diagram
- uml/implem/doctypes/UBL-OrderImplementationDiagram-1.0.gif
- Order Response implementation diagram
- uml/implem/doctypes/UBL-OrderResponseImplementationDiagram-1.0.gif
- Order Response Simple implementation diagram
- uml/implem/doctypes/UBL-OrderResponseSimpleImplementationDiagram-1.0.gif
- Order Change implementation diagram
- uml/implem/doctypes/UBL-OrderChangeImplementationDiagram-1.0.gif
- Order Cancellation implementation diagram
- uml/implem/doctypes/UBL-OrderCancellationImplementationDiagram-1.0.gif
- Despatch Advice implementation diagram
- uml/implem/doctypes/UBL-DespatchAdviceImplementationDiagram-1.0.gif
- Receipt Advice implementation diagram
- uml/implem/doctypes/UBL-ReceiptAdviceImplementationDiagram-1.0.gif
- Invoice implementation diagram
- uml/implem/doctypes/UBL-InvoiceImplementationDiagram-1.0.gif
In addition to the main document diagrams, this release contains ten class diagrams that present views of the packages of reusable components used in the documents. For example, the Order diagram includes associations to Party, SellerParty, and BuyerParty. The following implementation diagram shows these components in detail.
Figure B-8. Implementation Model for Party Components
The component implementation diagrams provided with UBL 1.0 are as follows:
- Address implementation diagram
- uml/implem/packages/UBL-AddressImplementationDiagram-1.0.gif
- Contract implementation diagram
- uml/implem/packages/UBL-ContractImplementationDiagram-1.0.gif
- Despatch Line implementation diagram
- uml/implem/packages/UBL-DespatchLineImplementationDiagram-1.0.gif
- Document Reference implementation diagram
- uml/implem/packages/UBL-DocumentReferenceImplementationDiagram-1.0.gif
- Hazardous Item implementation diagram
- uml/implem/packages/UBL-HazardousItemImplementationDiagram-1.0.gif
- Item implementation diagram
- uml/implem/packages/UBL-ItemImplementationDiagram-1.0.gif
- Party implementation diagram
- uml/implem/packages/UBL-PartyImplementationDiagram-1.0.gif
- Payment implementation diagram
- uml/implem/packages/UBL-PaymentImplementationDiagram-1.0.gif
- Procurement implementation diagram
- uml/implem/packages/UBL-ProcurementImplementationDiagram-1.0.gif
- Shipment implementation diagram
- uml/implem/packages/UBL-ShipmentImplementationDiagram-1.0.gif
- Tax implementation diagram
- uml/implem/packages/UBL-TaxImplementationDiagram-1.0.gif
Guidelines for performing a compatible customization of UBL schemas, together with suggestions for how to proceed when a compatible customization is not possible, can be found in this package at
The UBL Customization Guidelines are the product of the OASIS UBL Context Methodology Subcommittee. The work of the UBL CMSC can be viewed on the CMSC web page:
The UBL 1.0 package includes an extensive set of formatting specifications in a hyperdocument rooted at
This part of the package also includes PDF renderings of the example instances provided in Appendix D below.
The UBL Formatting Specifications are the product of the OASIS UBL Forms Presentation Subcommittee. The work of the UBL FPSC can be viewed on the FPSC web page:
This appendix provides example instances of UBL documents being used in two different versions of the order-to-invoice process. The first set of examples illustrates the buying of office supplies, and the second set illustrates the buying of joinery (building supplies). Also included are printed versions of each example document created in accordance with the formatting specifications referenced in Appendix C.
The buyer, Bill's Microdevices, orders several different items from an office supply store. The buyer knows the supplier's codes for the items and the price for each.
- Office supplies Order example instance
- xml/office/UBL-Order-1.0-Office-Example.xml
- Printouts
- fs/Order/pdf/OfficeOrder.Example-a4.pdf
- fs/Order/pdf/OfficeOrder.Example-us.pdf
The buyer decides to change the original order.
- Office supplies Order Change example instance
- xml/office/UBL-OrderChange-1.0-Office-Example.xml
- Printouts
- fs/OrderChange/pdf/OfficeOrderChange.Example-a4.pdf
- fs/OrderChange/pdf/OfficeOrderChange.Example-us.pdf
The seller, Joe's Office Supply, replies with an Order Response Simple to indicate the acceptance of the order. The seller also gives his reference number for the order, i.e., the sales order in his system, and tells the buyer whom to contact if he has any queries.
- Office supplies Order Response Simple example instance
- xml/office/UBL-OrderResponseSimple-1.0-Office-Example.xml
- Printouts
- fs/OrderResponseSimple/pdf/OfficeOrderResponseSimple.Example-a4.pdf
- fs/OrderResponseSimple/pdf/OfficeOrderResponseSimple.Example-us.pdf
The buyer cancels an Order (for purposes of illustration, not the same one).
- Office supplies Order Cancellation example instance
- xml/office/UBL-OrderCancellation-1.0-Office-Example.xml
- Printouts
- fs/OrderCancellation/pdf/OfficeOrderCancellation.Example-a4.pdf
- fs/OrderCancellation/pdf/OfficeOrderCancellation.Example-us.pdf
The seller advises the buyer of the despatch of the items ordered.
- Office supplies Despatch Advice example instance
- xml/office/UBL-DespatchAdvice-1.0-Office-Example.xml
- Printouts
- fs/DespatchAdvice/pdf/OfficeDespatchAdvice.Example-a4.pdf
- fs/DespatchAdvice/pdf/OfficeDespatchAdvice.Example-us.pdf
The buyer notifies the seller of missing items.
- Office supplies Receipt Advice example instance
- xml/office/UBL-ReceiptAdvice-1.0-Office-Example.xml
- Printouts
- fs/ReceiptAdvice/pdf/OfficeReceiptAdvice.Example-a4.pdf
- fs/ReceiptAdvice/pdf/OfficeReceiptAdvice.Example-us.pdf
The seller raises the Invoice automatically when the despatch occurs, and the resolution of shortages etc. is handled post-invoicing. The Invoice shows the tax amount. The seller notes that payment is due within 30 days of Invoice.
- Office supplies Invoice example instance
- xml/office/UBL-Invoice-1.0-Office-Example.xml
- Printouts
- fs/Invoice/pdf/OfficeInvoice.Example-a4.pdf
- fs/Invoice/pdf/OfficeInvoice.Example-us.pdf
The buyer, Jerry Builders, PLC. in the UK, orders a number of windows, a door set, and some lengths of timber for delivery to a building site. Jerry knows the supplier's codes for the items, and that he must also specify a number of physical attributes to get the precise item that he wants: some windows are asymmetric and are "handed" left or right; most door sets are handed, as they are hinged on one side; the wood and its finish must be specified, as must the "fittings" (handles, stays etc.). Items can be glazed in different ways. Loose timber is coded according to its cross section, and the length must be specified. While the buyer knows these things from the catalogue, he does not know the current prices or any discount rate he may get.
- Joinery Order example instance
- xml/joinery/UBL-Order-1.0-Joinery-Example.xml
- Printouts
- fs/Order/pdf/JoineryOrder.Example-a4.pdf
- fs/Order/pdf/JoineryOrder.Example-us.pdf
The seller, Specialist Windows PLC, replies with a detailed Order Response to indicate the unit price of each item and to inform the buyer of the trade discount that he will be given. At the same time, the seller gives his reference number for the order, i.e. the identity of the order in his system, and also tells the buyer whom to contact if he has any queries.
- Joinery Order Response example instance
- xml/joinery/UBL-OrderResponse-1.0-Joinery-Example.xml
- Printouts
- fs/OrderResponse/pdf/JoineryOrderResponse.Example-a4.pdf
- fs/OrderResponse/pdf/JoineryOrderResponse.Example-us.pdf
The seller advises the buyer of the despatch of the items ordered, which will in fact be delivered on two pallets (i.e., transportation units) identified as "A" and "B". The Despatch Advice lists the items in order line sequence and refers to the pallet on which the item is delivered.
- Joinery Despatch Advice example instance
- xml/joinery/UBL-DespatchAdvice-1.0-Joinery-Example.xml
- Printouts
- fs/DespatchAdvice/pdf/JoineryDespatchAdvice.Example-a4.pdf
- fs/DespatchAdvice/pdf/JoineryDespatchAdvice.Example-us.pdf
The Despatch Advice travels with the delivery; a paper copy is signed and returned as proof of receipt. Hence the UBL Receipt Advice is not used.
The Seller raises the Invoice automatically when the despatch occurs, and the resolution of any shortages is handled post-invoicing. The Invoice has to show the tax point date, the VAT (Value Added Tax) category to which the item belongs, and also the VAT rate and total for each tax category on the invoice. VAT is also applied to charges such as the delivery surcharge. In order to encourage speedy payment of the amount due, the Seller offers a discount for prompt settlement, which the buyer can deduct if paying within 30 days. (This example was written for a context in which regulations assume the VAT will be taken, so the tax here is calculated on the trade discounted total of line items plus any charges and less the settlement discount amount.)
- Joinery Invoice example instance
- xml/joinery/UBL-Invoice-1.0-Joinery-Example.xml
- Printouts
- fs/Invoice/pdf/JoineryInvoice.Example-a4.pdf
- fs/Invoice/pdf/JoineryInvoice.Example-us.pdf
This example is based on the products, product identification, business requirements, and practices of a real UK joinery manufacturer and sales company. It operates its own specialized transport fleet, delivering all over the United Kingdom and to offshore islands.
The code list schemas included in UBL 1.0 conform to the UBL specification for Code List Representation, which can be found in this package at
The UBL Code List Representation specification is the product of the OASIS UBL Code List Subcommittee. The work of the UBL CLSC can be viewed on the CLSC web page:
The UBL ASN.1 specification referenced below provides an alternative schema definition for UBL documents in accordance with ITU-T X.680-X.693 [ASN.1]. The UBL ASN.1 specification defines the same UBL documents as the UBL XSD schemas in Section 6 that constitute the normative definitions of valid UBL documents. The UBL ASN.1 XML schema enables ASN.1 tools to be used for UBL transfers, and in conjunction with the ASN.1 Packed Encoding Rules, it provides a specification for an efficient binary encoding of UBL messages.
- UBL ASN.1 Specification
- asn/ASN.1-UBL-1.0.html
The ASN.1 UBL specification was created using a tool from OSS Nokalva (http://www.oss.com/) that conforms to ITU-T Recommendation X.694 | ISO/IEC 8825-5 for converting XSD Schema to ASN.1. After conversion, the generated ASN.1 was formatted by the PrettyPrint tool at the ASN.1 Information Site (http://asn1.elibel.tm.fr) to produce the HTML file included in this package.
UBL 1.0 achieves the basic objective of the first phase of the UBL charter — to develop a workable standard library of XML business documents. The second phase (UBL 2.0) is intended to produce additions to the UBL library and schema set and a mechanism for the automatic generation of context-specific business schemas.
Between these milestones lie a number of work items that for one reason or another could not be completed in time for delivery of UBL 1.0. Some of these items represent work of continuing interest; others represent cases where an issue could not achieve a consensus solution within the time set for UBL 1.0 delivery but for which an acceptable short-term strategy could be adopted with little or no impact on the long-term validity of UBL 1.0 document instances. The UBL TC intends to resolve these issues and release an updated version called UBL 1.1 that will be backward-compatible with UBL 1.0 instances.
In the following, these work items have been loosely grouped under four headings: NDR Work Items, Interoperability Work Items, Registry Work Items, and Localization Work Items. Persons interested in participating in this program of work are invited to join the OASIS UBL TC.
The following items are related to UBL Naming and Design Rules (NDR).
Time constraints prevented completion of the UBL Naming and Design Rules (NDR) document as a separate specification for delivery with UBL 1.0; the document included in this package and referenced as [NDR] contains only the rules checklist for 1.0. Work continues to prepare the NDR document for submission as a separate OASIS technical specification.
The UBL Code List Subcommittee has produced a comprehensive solution for code lists (see Appendix E) that relies upon XSD substitution groups for code list customization. Lacking a clear industry consensus on the use of XSD substitution groups in business document schemas, the UBL TC has deferred the adoption of this extension mechanism for code lists pending further discussion. Care has been taken to construct UBL 1.0 in a way that will allow the adoption of substitution groups (if deemed appropriate) in later releases without invalidating UBL 1.0 instances.
It is an open question whether it is better to import the codelist schema modules (Section 6.3) indirectly via the Specialized Datatype schema (Section 6.2.2) or directly into the Common Aggregate Component schema (Section 6.2.1) and any individual document schemas where they are used. In UBL 1.0, codelist schema modules are imported directly, but concerns have been raised regarding a possible impact on performance. Feedback from UBL 1.0 implementation will be relied upon in resolving this issue. A change to the alternative is not expected to affect UBL 1.0 instances.
In UBL 1.0, all BBIE properties are declared as elements and defined as complex types in the Common Basic Components schema (Section 6.2.1). Alternatively, the qualified BBIE property elements could be declared in either the Common Aggregate Components schema or in the individual document schemas where they are used. This issue remains open, but any change in future releases will not affect UBL 1.0 instances.
The following issues relate to the storage and registration of UBL schemas.
UBL NDR identified a requirement for absolute path names for schema locations as a necessary requirement for standards based schemas to ensure consistency, clarity, and absolute assurances that the UBL normative schemas are in fact being used. However, current OASIS architecture limitations preclude the availability of a suitable registry/repository to support this requirement. As a result, UBL 1.0 has been released using relative path names for the location of schemas in order to facilitate offline validation and to work around those limitations. Use of absolute paths and a registry for the component library will be implemented in a future version as the supporting infrastructure becomes available.
UBL 1.0 assumes that the version number of each UBL datatype and BIE is also 1.0. However, there is some debate as to whether this is a schema construct artifact or a storage artifact. The outcome of this decision may result in a requirement to assign a version number in the annotation documentation for each datatype and BIE schema construct.
The following work items relate to the interoperability of UBL documents across industries and in relation to other business document standards.
While much initial work has been done toward defining the concept of UBL conformance in the UBL 1.0 Customization Guidelines (see Appendix B.7), further work is necessary to create a definition of UBL conformance that is usable in legal and regulatory contexts.
It is considered likely that UBL 1.0 will be modified according to the UBL Customization Guidelines to create versions that are standard within particular industries and geographical regions. Further work is needed to develop guidelines specific to this use case.
The schemas for Core Component Types and Datatypes included in this package (Section 6.2.2) were developed in cooperation with representatives of the Open Applications Group, Inc., but the versions currently used by the two organizations are not yet identical. Differences between the CCTS schemas used in UBL 1.0 and OAGIS 9.0 have been identified in these five areas:
Naming of Supplementary Components as attributes
Use of XSD normalizedString for code, identifier, and text components
Use of XSD built-in dataypes requiring format Supplementary Components (Date Time, Indicator and Numeric)
Restrictions on Binary Object for Graphic, Picture, Sound and Video data type
Patterns for Indicator data type
A common set of CCTS schemas are expected to be available for UBL 1.1 and will be included at that time. This is not expected to affect the validity of UBL 1.0 instances.
As an implementation of [CCTS], UBL supports the concept of a common semantic library of business components. To achieve this, UBL is working with the UN/CEFACT International Trade and Business Processes Working Group on Harmonization, known as TBG17 (http://webster.disa.org/cefact-groups/tbg/wg/tbg17_main.cfm). This group is responsible for consistency and harmonization of business process models and core components across business domains and sectors, contributing to a concise and well-defined glossary of business terms, business data semantic definitions, and structuring of data exchanges. Cooperation with TBG17 is a continuing work item for UBL.
While the delivery of an automatic context methodology belongs to UBL 2.0, work on this item continues in the UBL 1.1 time frame. This includes further refinement of the Customization Guidelines referenced in B.7 of this specification.
UBL has formed several localization subcommittees (LSCs) to translate the UBL specification and associated documentation into languages other than English and to represent the UBL effort in non-English-speaking regional contexts. These regional initiatives will account for much of the work to be performed in the UBL 1.1 time frame. As of April 2004, UBL localization subcommittees had been established for Chinese, Japanese, Korean, and Spanish.
Copyright © 2001-2004 OASIS Open, Inc. All Rights Reserved.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


text:
On a global scale, food systems are facing multiple challenges. The way food is produced, processed, packaged, distributed and consumed hinders food security and harms the planet. Climate-related challenges such as scarcity, soil erosion and drought are leading to reduced food production, and supply chains are experiencing disruptions caused by COVID-19.
At the same time, many countries are experiencing the double burden of malnutrition, where undernutrition coexists with being overweight, obesity and other diet-related diseases. Add to this the projected population growth, where it is expected we will reach 9.7 billion6 people by 2050, and the demand for safe, nutritious food escalates.
Despite the challenges with food accessibility, one-third of the food produced is lost or wasted4. Food loss mainly occurs during production or because food is discarded and never gets packaged, whereas food waste can be driven by short shelf life experienced by retailers and unsustainable consumption practices of consumers.
Food loss and waste are particularly harmful considering that food systems account for over one third of global greenhouse gas emissions. The emissions produced by the processes involved in food systems are increasing rapidly, especially in some developing countries5.
As food travels through the supply chain towards its destination, it can also be deterred by the lack of infrastructure in many countries. The lack of ability to get food safely and securely from farms to people's homes is a driver of hunger in some developing countries. Accessible food processing and packaging solutions can play a role in ensuring that safe and nutritious food is made available in remote areas.
To address global food challenges, we need to look at entire food systems and work towards making them more secure and more sustainable: The UN says that food security means that all people, at all times, have physical, social and economic access to sufficient, safe and nutritious food; and sustainable food systems mean growing, producing, processing, packaging, distributing and consuming food without exhausting the earth's resources or negatively impacting the planet7.
At Tetra Pak, we want to play our part in moving the world's food systems forward. With the right expertise, technology and partnerships, we believe we can make a real difference. That is why we continue to commit to making food safe and available everywhere. And we promise to do that in a way that protects what's good: protecting food, people and the planet.
1The term 'food systems' refers to all the elements and activities related to producing and consuming food, and their effects, including economic, health, and environmental outcomes (OECD, https://www.oecd.org/food-systems, 2023).
8By positive impact we mean driving better outcome for our own workforce, workers and communities in our supply chain, workers in collection and recycling and people in our value chain affected by climate change and the transition to net-zero in the areas of labour, discrimination, hazardous working conditions and sustainable income, among others

subset: commoncrawl


text:
Wordscapes November 7 2020
Wordscapes Daily Puzzle November 7 2020, full answers with image hint and all answers is given on this post. Daily puzzle is an updated section of wordscapes that bring brand new puzzles for you every day. We have solved Wordscapes Daily Puzzle November 7 2020 for you and put the answers here. Hope you enjoy playing this fantastic game. Come back tomorrow for new daily puzzles. If the game is too difficult for you, don't hesitate to ask questions in the comments. You can find all day's answers here.
Here's the answers for Wordscapes November 7 2020 :
Last Answer : MAY.
All Answers for Wordscapes Daily Puzzle Here : Wordscapes Daily Puzzle Answers
About Wordscapes Game : "Can you solve all the cross word puzzles? Even with unlimited tries it's a challenge! This text twist of a word game is tremendous brain challenging fun. Enjoy modern word puzzles with the best of word searching, anagrams, and crosswords! You'll never experience a dull moment after you try this addicting word puzzle game! Play this crossword puzzle once and just you won't be able to put it down."
If you need more help please watch detailed walkthrough in this video :
You can download and play this popular word game, Wordscapes here :


text:
Ganges River Dolphin in dire straits
Dolphin hotspots must be protected if the Ganges River Dolphin (Platanista gangetica gangetica) is to survive in the Brahmaputra river system, according to a recent study.
Photo: Dr. Wakid Abdul
Estimates have put the total population of the Ganges River Dolphins at around 2,000. Out of these, between 240 to 300 inhabit the Brahmaputra River system in India, according to a recent survey by an IUCN Sir Peter Scott Fund project.
"Our research shows accidental killing through fisheries by-catch, followed by poaching for oil, are the major threats to the dolphins of the Brahmaputra river system," says Project Leader Abdul Wakid. "Their habitat is also being degraded by human activities. Dam building and a proposed seismsic survey in the Brahmaputra river are potential threats."
The project, funded by Fondation Ensemble, was prompted by the need for some robust dolphin population data after Oil India Ltd. proposed to start prospecting for oil along the bed of the Brahmaputra River using air guns and explosives.
The research identified eight river sections as potential protected areas and community-based dolphin conservation as the best strategy to save the dolphins.
"The Brahmaputra River is very important habitat for these endangered dolphins," says Gill Braulik, of IUCN's Cetacean Specialist Group. "To protect them it is vital that we involve local river communities. In some places, like in the Kukurmara area of Kulsi River, for example, the dolphins are a tourist attraction due to protection by local communities. But in other areas, dolphins are accidentally killed in fishing nets or are sometimes deliberately caught and killed for their oil."
The project carried out 32 awareness campaigns along the Brahmaputra valley, focusing on fishing communities in areas surrounding dolphin hotspots.
The Ganges River Dolphin is found mainly in the Ganges and Brahmaputra river systems in India and Bangladesh. This survey concentrated on the 1,044km stretch of dolphin-inhabited Brahmaputra River system, primarily in Assam of North East India. In a 2005 survey in the same river stretch by the same investigating group a best estimate of 250 dolphins was recorded.
Full report: https://www.iucn.org/downloads/brahmaputra_river_dolphins___psf_final_report.pdf
For more information or to set up interviews, please contact:
- Sarah Horsley, IUCN Media Relations Officer, t +41 22 999 0127, m +41 79 528 3486, e firstname.lastname@example.com
- Lynne Labanne, IUCN Species Programme, t +41 22 999 0153, e email@example.com
Photos: https://www.iucn.org/about/work/programmes/species/about_ssc/sir_peter_scott_fund/psf_projects/psf_ganges_river_dolphin/


text:
Debuted in 1980 the Audi Quattro is mostly known as a rally icon, having enjoyed great success in the WRC mostly thanks to its innovative 4-wheel drive system that took the WRC by storm.
80% Combed Cotton, 17% Polyamide, 3% Elastane.
We use seamless knitting to create a sock with no stitches.
More Information: HeelTread.com


text:
Steve Wozniak
Co-Founder, Apple
A Silicon Valley icon and philanthropist for more than thirty years, Steve Wozniak has helped shape the computing industry with his design of Apple's first line of products the Apple I and II and influenced the popular Macintosh. In 1976, Wozniak and Steve Jobs founded Apple Computer Inc. with Wozniak's Apple I personal computer. The following year, he introduced his Apple II personal computer, featuring a central processing unit, a keyboard, color graphics, and a floppy disk drive. The Apple II was integral in launching the personal computer industry.


text:
Sakura Wars
Sakura Wars
Sakura travels to the capital with aspirations of defending the city from the demonic forces of the Black Sanctum Council like her father before her. However, things are not as she imagined as in addition to using her great spiritual energy to pilot a mech called a Kobu, she must also perform on stage as an actor as The Imperial Flower Division's cover is an art theater. Making a fool of herself and ruining a production gets her on everyone's bad side and somehow she must learn to work with them as well as prevent the enemy from destroying several shrines which protect the city. Genres: action, adventure, science fiction Themes: Mecha, Real Robot
You may also like


text:
Thanks to the generous invitation of the Kingdom of Bahrain, fourteen out of the eighteen States Parties from the Arab Region met in Manama to launch the second cycle of the Periodic Reporting decided by the World Heritage Committee at its 32nd session in Quebec City (July 2008).
Two days of the meeting were devoted to training for the drafting of Statements of Outstanding Universal Value for properties already inscribed, followed by two days of explanations regarding the Periodic Reporting process, notably the filling out of the Questionnaire. The new questionnaire, adopted by the World Heritage Committee, will be answered directly on-line by the national focal points designated by their country. Three sub-regional workshops are foreseen to take place in April 2009 as well as a final Regional meeting in December 2009, to take stock of the exercise's results and to draft an Action Plan for future activities in the Region according to the needs identified during the process.


text:
Autumn Apple Crisp2018-01-31 15:26:28
Besides pumpkins, apples are one of the most used ingredients in autumn recipes, and with all of the orchards around Virginia, we are certainly in no short supply of this delicious fruit. There is a humongous variety of apple-based recipes floating around the world wide web, so perhaps you're having difficulty in locating the perfect dish. To lessen your stress and shorten your search time, enjoy one particularly delectable recipe (which can be found in Bob Greene's The Get With the Program! Guide to Good Eating) that we've selected for the delight of your taste buds: Ingredients: 2 cups apples (preferably Granny Smiths), peeled, cored, and sliced 2 tbsp sugar or sugar substitute 1/4 cup apple juice 1 tbsp fresh lemon juice 2 tsp cornstarch 1 tsp ground cinnamon Pinch of nutmeg Topping Ingredients: 1/2 cup walnuts or almonds, finely chopped 1/2 cup old-fashioned rolled oats 1/2 cup brown sugar 2 tbsp all-purpose flour 2 tbsp softened butter Preheat the oven to 350. Stir apples, sugar, apple juice, lemon juice, cornstarch, cinnamon, and nutmeg until well combined. Set aside. To make the oatmeal topping, mix together the walnuts or almonds, oats, brown sugar, flour, and butter. Place the apple mixture in an 8-inch square baking dish. Sprinkle the topping over the apples and bake for 25 to 30 minutes, until the apples are cooked through and the topping is browned. Serve with cool whip or vanilla ice cream. By Tara Stoll


text:
Amateur Night (2016)
Watch Amateur Night (2016) full movies online kisscartoon.
Synopsis: Guy Carter is an award-winning graduate student of architecture. He's got a beautiful wife and a baby on the way. The problem? He doesn't have "his ducks in a row," which only fuels his doubts about being a good father. Guy has been trying to find work in his field for a year with no luck. At wit's end, his wife Anne finds him a job as a 'driver' on Craigslist. Guy shows up for the interview thinking he'll be delivering pizzas, but quickly realizes it's a job driving prostitutes. With money too scarce to turn down, he goes for it- which is where he meets Nikki, the tough-as-nails, unapologetic sex worker, and her two hilarious and foul-mouthed cohorts, Jaxi and Fallon. As reluctant driver and protector Guy is thrust into a world of rockin' women and feeble men. Over the course of one wild and sordid night, and several 'come-to-Jesus' moments, Guy proves to Nikki, and himself, that he does have what it takes to be the responsible father his family deserves.
Directors: Lisa Addario, Joe Syracuse
Writers: Lisa Addario, Joe Syracuse
Stars: Jason Biggs, Janet Montgomery, Ashley Tisdale


text:
Operating Facilities - Sasol
Production of liquid fuels and chemicals from coal on a large scale was practiced in South Africa for decades at Sasol Synfuels' Sasol II and Sasol III, two Fischer-Tropsch (FT) synthesis-based fuels production plants in Secunda, South Africa. Construction of Sasol II began in the mid-1970s, with operation of the two plants commencing in the early 1980s. The two plants contain 80 Sasol-Lurgi Fixed Bed Dry Bottom (FBDB) gasifiers, and total output from both plants is approximately 150,000 barrels per day (bpd), reaching 160,000 bpd in 2006. The feedstock for the plants is sub-bituminous coal supplied by Sasol Mining, a sister company of Sasol Synfuels. Natural gas is also used as a supplemental feedstock. A proprietary iron-based FT process is used to convert the synthesis gas (syngas) produced by the gasifiers to gasoline, light olefins (alkenes), and a variety of other products.
Project Participants
The South African Coal Oil and Gas Corporation was founded in 1950, amid the realization that South Africa lacked crude oil reserves. The company was formed to protect against the country's increasing imports of crude oil. Today, Sasol Limited is headquartered in Johannesburg, South Africa, and is engaged in commercial production and marketing of chemicals and liquid fuels, in addition to developing interests in oil and gas exploration. The company is now comprised of a diverse group of businesses, including Sasol Synfuels, with a total of 50 entities worldwide.
Plant Description
Coal produced by Sasol Mining is sent to the Secunda petrochemical plant. The coal is converted in the Lurgi gasifiers into a raw product gas with the addition of steam and oxygen. The produced syngas is then cooled, cleaned and conditioned as it leaves the gasifier, producing the first level of co-products as they condense or are recovered from the stream: tars, oils and pitches, ammonia, sulfur and phenols.
Once purified, the syngas is sent to a suite of nine Sasol Advanced Synthol (SAS) reactors where it is reacted in the presence of a fused iron-based catalyst at elevated pressure (~ 350 psi) and a temperature of about 350°C, producing hydrocarbons along with reaction water and oxygenated hydrocarbons. The reaction water and oxygenated hydrocarbons are recovered, purified, and then marketed as byproducts.
The hydrocarbons from the SAS reactors are cooled until most of the components are liquefied before fractionation is used to separate the various hydrocarbon-rich fractions. Methane rich gas is also produced in this process and is converted to syngas via autothermal reforming for process recycle and sale as pipeline gas. The recovered product hydrocarbons are then converted into a wide range of saleable products, as shown in the following process diagram. Note that the Secunda plants use the High Temperature Syngas Conversion technology.
|References/Further Reading
Liquid Fuels


text:
Our Services
We specialize in more types of surgery than any other pediatric center in Oregon and southwest Washington.
You and your child have access to complete evaluation, diagnosis, treatment and follow-up for everything from the most common conditions to the rarest and most complex.
Your child receives personalized care from highly trained surgical specialists and a multi-specialty team of experts who work together to provide your child the very best care.


text:
While Berlin was putting its best foot forward during the 1st Annual Jazz and Blues Bash, its mayor passed away at his home of cardiac arrest.
Mayor Tom Cardinale would have enjoyed the scene on Main Street last Saturday. Mixing it up with residents and visitors alike was one of his favorite things to do. He enjoyed the personal aspects of being mayor. As obvious as that was, it was equally evident he took the shortfalls of life as a politician to heart. He had thin skin and did not revel in the inevitable criticism that comes with public life. He took it all too personal.
Even Cardinale would admit his term did not go as he anticipated. He had unfinished business. Perhaps, that's why he announced back in January, 10 months before the election, he would be filing for another term. The fact is his term was marked by notable failures, such as the electric plant referendum, a lawsuit by the town's former finance administrator who he fired and a miscommunication fiasco involving a planning commission member who had brain cancer, to name a few, but that does not speak to what Cardinale was about. He was a much better man than a politician.
Cardinale deserves this community's respect. He was not perfect. He readily admitted his faults when it was necessary. He wore his heart on his sleeve and admitted he mishandled a situation when it happened. That's a sign of a good man.
What we admired about Cardinale was he saw something he did not like and got off the proverbial sideline and put himself in the game. He was a political neophyte, having never held a public or appointed office, but he overwhelmingly defeated an entrenched incumbent to become mayor in 2004. His main reason for entering politics was a persistent flooding issue around his neighborhood. Unfortunately, that issue never got the town's full attention under Cardinale, but that's how politics and government work.
Berlin is a town with a lot of issues. It's a wonderful and charming place to work, live and visit, but there are a number of serious problems, such as its debt service, the growing EDU allocation dilemma, faulty roads and employee turnover. Cardinale tried to rectify these issues and others, but no single person can resolve them. It will take years to work these out.
Today, we choose to remember Cardinale as a man who did not like what he saw in his new hometown and tried to do something about it. We will remember him for his huge smile and charitable spirit, evidenced each year around the holidays when he gave out bikes to underprivileged youngsters. The man cared about Berlin.
Although some disagreed with how he did his job, Cardinale should be remembered fondly for his heart and intent. He had a burning desire to serve the people and in this society that's commendable because it's a thankless job with long hours, lots of headaches and few, if any, rewards.


text:
Assassin's Creed IV: Black Flag is a vast game. Edward Kenway's groovy pirate adventure will likely devour the free time of more than a few history buffs over the next few weeks. But while all pirates sail the same seas, not all of them are as smart about it.
After spending 30+ hours adventuring through Black Flag's version of the Caribbean, I thought I'd jot down some tips to help everyone else have smoother sailing. Ready? Let's go.
Play online, if you can.
I played the bulk of Black Flag more or less offline on a debug PS3, and after talking to Stephen (who played a retail version of the game online), it became clear that playing online makes it a lot easier to make money. That's because the game contains online-only "social challenges"—gold-laden ships, hidden treasure and rare harpooning challenges that open up and offer you fabulous cash rewards. Stephen had a much easier time paying for the upgrades he needed in the early goings than I did. The "Fleet" minigame, additionally, is only available online. I found it too tedious to sink much time into it, but it does seem like it could be a decent source of income if you dedicate some time to it.
That said, if you want to make the game more of a challenge, play offline. I can attest that it's doable, it'll just mean more grinding for less money in the early goings.
Don't reduce your wanted level.
Money won't be too much of a problem as long as you're playing online, but materials will be. You'll need lots of metal to upgrade the Jackdaw and her guns, and the easiest way to get that is by boarding and sacking military ships. However, those can be hard to come by in the early goings… unless you get a wanted level. After you take out a few ships, you'll get a GTA-style wanted ranking and red-sailed "pirate hunters" will come after you. These ships always have metal, and can be a great way to farm for upgrade materials. After taking one down, you'll have the option to reset your wanted level, but don't do that. Let it keep climbing, and keep on taking down ships. In about an hour, you can earn a ton of metal and even if the high-level mega-ships that eventually come after you take you out, you won't lose any of your earnings.
Sail a lot in the early goings.
One of the best things about Black Flag is that there's a new, incredibly useful fast-travel system. In the early goings of the game, you'll have to sail a lot to get where you're going. This is good: Be sure to sail over and pick up any loot you may pass by. It's very a cinch to grab it and it'll add up.
Take out a lot of ships, too.
You may want to power through the story missions of Black Flag, but it's worth taking the time to do some real piracy. If you take down a bunch of ships, it'll be much easier to upgrade the Jackdaw for the more difficult later missions. Also, piracy is fun.
Level up your swivel guns early.
Of all the upgrades you can give the Jackdaw, armor and main cannons seem like the two most useful. And they are useful. But the swivel guns—the guns that automatically target an enemy ship's weak points after scoring a hit with cannons—are the Jackdaw's secret weapon. They're the thing that allows you to take down three powerful ships without sinking yourself. Upgrade them as soon as you can to do more damage and fire more shots.
Use the swivel gun before boarding.
You've got a lot of freedom when it comes to boarding ships, but before you leave the Jackdaw, be sure to take the enemy-facing swivel gun and take out as many crew members as possible. It's surprisingly easy to get killed while swordfighting on the enemy deck, so the more dudes you can kill before leaping over, the better your chances will be.
When fighting more than one ship, board and repair mid-fight.
This is a tricky trick for tricksters, but it makes it much easier to survive a pitched sea-battle. If you're taking on more than one high-level ship, focus your attention on just one of them. Cripple it and board it, and when given the option, choose to repair your ship. Voila! It's like grabbing a health-orb in the middle of a fight.
You'll know a ship is clear for boarding when its powder keg explodes and its sails catch fire. It'll look like it's going down, but be careful not to loose another fusillade into it, or it'll sink and you'll lose your chance to board. The moment you begin boarding, the other ships will stop shooting you, so you'll be in the clear.
Don't forget about your mortars.
This is the other biggest ship-on-ship tip: Don't forget about your mortars! You'll get them early in the game, and can access them with the L2 button (LB on Xbox). They're incredibly powerful, and much more accurate than the mortars that enemies will use against you. If you're taking on a powerful enemy ship, soften them up with mortars beforehand. Mortars are even more useful on forts, which can take a lot of punishment from your main guns but seem significantly more vulnerable to mortar rounds. You also won't come across mortar ammo on the seas as often, so be sure to stock up when you're on land!
You can buy the materials for some important upgrades.
At general stores, you can actually buy the animals hides you'll need for some basic upgrades that'll make your life a lot easier. Specifically, the hides needed to make ammo pouches for your blowgun and pistols, which will help you go a lot longer without restocking.
Pay attention to the map of Templar Hunt quests.
There are four Templar Hunt quests that you can undertake to unlock a decent set of Templar armor. The armor itself isn't my favorite—it doesn't make Edward that much stronger and it looks funny—but the missions to get the armor are pretty cool. However, while three of the missions are located in the three main cities, the fourth one is on an island northwest of Kingston. It's marked on a map that you can find in the plantation house on Great Inagua, but it's easy to forget where it is and spend ages scouring the map for it. Make a note early on for where to find it.
Fight smart: Use guns and smoke bombs.
The combat in Black Flag is a good degree more challenging than past games in the series. As a result, you'll want to fight smart, and sometimes dirty. If you're in the middle of a ship-boarding, low on health and worried about having to start over, throw down a smoke bomb. It's a bit of a cheat, a get-out-of-jail free card that'll let you effortlessly kill three or four dudes, even the heavies. But hey, no one said pirates fight with honor.
Learn the juke.
When running around on land, when you tease the thumbstick left or right, Edward will "Juke" without fully turning himself. It's a good move to master, not only because it looks cool but because it can help you dodge enemies and enemy fire without deviating from your path.
When sneaking, tag everyone.
Stealth in Black Flag is greatly improved compared to past games in the series. One of the things that makes sneaking a lot more fun is that you can now tag enemy patrols and keep an eye on them through walls. Edward can tag a pretty large number of enemies, and every time you head into a new area, don't forget to snap on Eagle Vision and capture as many enemies as you can. It'll make your life a lot easier.
In the modern-day stuff, seek out the audio logs.
There are a lot of things you can collect in the offices of Abstergo Entertainment. Without spoiling too much, there are audio diaries that are easily the most rewarding things to collect, particularly for longtime fans of the series. Take the time to track those down and listen to them.
Don't sink money into your pirate hideout.
Early in the game, Edward unlocks a hideout on Great Inagua. If you want, you can sink money into upgrading this place. Don't. The upgrades are mostly cosmetic, and there are far more worthy things to spend money on.
Pay attention to optional mission objectives.
The optional mission-objectives aren't just bonus challenges, they offer great ideas on how you can approach each one. If an optional challenges says "Take out five guards from cover," you know there'll be a lot of cover to use. If it says "Don't get spotted," you know it's possible to play the entire mission from stealth. "Air assassinate your target," "Use a rope swing to assassinate your target," and so on and so forth.
Remember to sell your sugar and rum.
Two of the materials you'll loot from enemy ships have no use except to be converted into cash. In the early goings, don't forget to sell sugar and rum as soon as you can, since you won't need them for anything else.
Buy the black privateer outfit so you look like the Dread Pirate Roberts.
The white and blue Assassin's robes are all well and good, but let's be honest: black is way cooler. It's worth dropping 5k on the black Privateer outfit, which will make Edward look ready to take on an army of ROUSes.
Chase down sea shanties. They are the best.
Black Flag's collectible sea shanties are the best. With each one you capture, your crew will learn a new song and sing it the next time you travel. You'll quickly get tired of hearing the same ones over and over, so it's worth taking the time to run down new shanties whenever you see one. For bonus points, try to figure out which crew members are singing which songs—some of the guys have lovely voices, and some are… well, let's just say "untrained."
Those tips should make for smoother sailing through Black Flag's deadly waters. Keep a hand on the wheel and an eye on the horizon, and remember: Always steer into rogue waves.
To contact the author of this post, write to firstname.lastname@example.com or find him on Twitter @kirkhamilton.


text: Dream Lens Irix 15mm f/2.4 Ultra-Wide Announced with Hi-tech Features. TH Swiss has announced a new line up of lenses for photographers. The first lens that they introduced is Irix 15mm f/2.4 . With Irix 15mm they claim to provide the newest technology with the classic design. The classic design of …Read More »