OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [ubl-lcsc] Agenda for the UBL Library Content subcommittee tol be heldon TUESDAY 14th January between 8 and 10 a.m California time

The regular meeting of the UBL Library Content subcommittee will be held 
on TUESDAY 14th January between 8 and 10 a.m California time


Call number is 877.494.5165. International number is 405.319.0674
Participant code is 133929.

NOTE: This is our REGULAR call number.  You may be placed on hold until 
Bill Meadows joins the call.

The agenda will be:

1. Welcome from Chair and  appointment of Secretary to take minutes

2. Acceptance of previous minutes

3. Status of Release 0p70
Part 2 Document (see attached)
UML Diagrams
Sample instances
Stylesheet Library

4. Plan for Processing Comments

5. Work plan and schedule

6. Denver Plenary preparation

7. Other Business

tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142 

Title: Universal Business Language — Library Content Public Review

Universal Business Language — Library Content Public Review

Dated: January 13th 2003


The Universal Business Language (UBL) Library is…

The Library has been designed as a collection of object classes and associations expressed as a conceptual model. Specific document types are then assembled from these business information entities (BIES) by organizing them into a specific hierarchy. These hierarchical models are then transformed using the UBL Naming and Design rules [NDR] into XML Schema syntax[XSD1][XSD2]. The analysis and design processes developed by the UBL Library Content team are described in Appendix A.

The UBL library is intended for use in business data contexts beyond the specific set of document types provided in this specification.  For example, the document Order Response may have a limited application, but the re-usable component Party or Item will have relevance to many applications.

Status:  This draft is intended for limited review pending a more general public review commencing January 20th 2003.

1 Scope

UBL establishes a system for the concrete representation of documents to be used in electronic commerce.

The Library Content part of UBL specifies a library of business information entities to be used in the construction of business documents together with a set of common XML business documents assembled from entities in the library.

2 Normative References

[11179] International Standards Organisation's Specification and Standardization of Data Elements for Information Technology
       http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=19184&ICS1= 35&ICS2=40&ICS3=
[CCTS] UN/CEFACT ebXML Core Components Technical Specification
[NDR]  Universal Business Language Naming and Design Rules
[UML]  Unified Modeling Language 1.4 (formal/01-09-67)

[XML]  Extensible Markup Language (XML) 1.0 (Second Edition),
       W3C Recommendation 6 October 2000

[XSD1] XML Schema Part 1: Structures, W3C Recommendation 2 May

[XSD2] XML Schema Part 2: Datatypes, W3C Recommendation 02 May 2001

3 Terms and Definitions

Business Context
the formal description of a specific business circumstance as identified by the values of a set of context categories, allowing different business circumstances to be uniquely distinguished
Class Diagram
a graphical notation used by the UML [UML] to describe the static structure of a system, including object classes and their associations
a modular and self-contained group of data components
aggregating components (nested elements in an XML schema [XML])
the circumstance or events that form the environment within which something exists or takes place
Dependency Diagram
a refinement of a class diagram that emphasises the dependent associations to between object classes
Document Assembly
a description of an hierarchical pathway through a normalized model
Hierarchical Model
a tree-structured model that can be implemented as a document schema
a formal technique for identifying and defining functional dependencies
Normalized Model
a representation of normalized data components
an XML document definition based on the W3C XML Schema language [XSD1][XSD2]
any XML document definition 
Spreadsheet Model
a representation of a data model in tabular form

The terms Core Component and Business Information Entity are used in this specification with their meanings given in [CCTS].

The terms Object Class, Property and Representation Term are used in this specification with their meanings given in [ISO11179].

4 Symbols and Abbreviations

an Aggregate Business Information Entity
an Aggregate Core Component
an Association Business Information Entity
an Association Core Component
a Basic Business Information Entity
a Basic Core Component
a Business Information Entity
a Core Component
the European Article Numbering Association
Electronic Data Interchange
the International Standards Organisation
UBL Naming and Design Rules [NDR]
the Unified Modeling Language[UML]
the United Nations Centre for Trade Facilitation and Electronic Business
the Extensible Markup Language [XML] 
the World Wide Web Consortium's XML Schema Language [XSD1][XSD2] 

5 UBL Context and Business Rules

The specific context adopted for UBL release 0p70 is based on a typical trading cycle.  This section describes the scenario and choreography as well as highlighting some of the business rules used in developing this set of documents.

The design of this particular set of UBL documents also allows it to be used as a basis for extension to create more function-rich, but separately defined, scenarios. When that occurs, it is expected that this section will become one of a list of ALL available Scenarios from different, complementary, sources. Such a list and descriptions need to be constructed in such a way that a newcomer will be able to readily identify the scenario that exactly, or most closely, fits their requirement and manner of operation.

5.1 Scenario - The UBL Trading Cycle

This model addresses the requirements of a basic, usable, trading cycle from Order to Invoice between Buyer and Seller. It includes specifications for:

It provides for:

It does not cater for:

5.2 Scenario – Others

Different business scenarios to meet different ways of trading cycle operation can, and should, be developed by separate, appropriate, teams of business and modelling experts. Ideally they should take advantage of the basic UBL model as a starting point and as an example, and all will need to go through an independent harmonisation review to encourage and to ensure inter-operability, to reduce ambiguity, and to avoid unnecessary overlap.

Suggested other scenarios, for separate development, include situations of:

Other scenarios that are already in development and that should be included in the catalogue of business scenarios include:


It is expected that each of the above suggestions will become, at least, one separate scenario with a carefully defined scope that describes what the scenario does and does not cover.

It is also expected that wherever possible as much of each model and 'document' will be as common in design as is possible.

It is also expected that there will be a carefully judged balance between, on the one hand, having too many separate and different scenarios and, on the other hand, too few generic 'all-things-to-all-folks' scenarios.

5.3 UBL Op v0p70 Trading Cycle Scenario

Items are ordered by the Buyer from the Seller. The Buyer and Seller may be in the same country, or in different countries. The Seller confirms with either an Order Response (simple), or an Order Response (complex) if it is necessary to provide the Buyer with additional information. The Seller fulfils the order by sending a Despatch Advice and supplying the items requested. The Buyer returns a Receipt Advice to confirm items have been received. The Seller invoices the items that have been provided. The Buyer reconciles the invoice to the despatch advice and order, and makes a payment which covers one or more invoices within the payment period defined in the invoice payment terms.

Figure 1 - Table of Trade Cycle

In the simplest of cases, it is not anticipated that there will be any need to change order details. Complete cancellation may be allowed. The Buyer may indicate potential substitutes that are acceptable; the Seller may advise substitutes which will be made, or changes necessary, using the Order Response (complex).

The Order can subsequently be modified by the Buyer cancelling the original Order and replacing it with a new Order. 

5.3.1 Order

The Order may specify Charge Payment (e.g. freight, documentation etc) instructions 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 overall allows only for specification of Currency (e.g. £, $, € etc by ISO currency code) for Pricing, for Invoice presentation, for Tax accounting. In the case of International freight/documentation charges, it may also be necessary to specify the Currency.

Trade discount may be specified at Order Header level. The Buyer may not know the trade discount, in which case it is not specified. This makes a detailed Order Response (complex) necessary [See Order Response (Complex)].

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:

The Order provides for multiple Order Item Lines. Order Item Line

Each Order Item 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 Item Line may provide instructions for delivery. Partial shipment indication is also allowed, insofar as the only information needed is a yes/no 'partial shipment allowed' indicator for each Order Item Line.

For each Order Item Line, an Allowable Substitute can be included. The substitute item may be specified by any one of the range of Item identifiers. The specified Quantity may change e.g. 20x6-packs substituting for 10x12-packs. Item Specification

An Item Identifier identifies each Item (e.g. a product identifier), which shall be one of the following:

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: Item Requiring Description

This is an item that is not identified by an unambiguous, machine processable, product code and where it is necessary to provide additional descriptive information about the item to precisely identify what is required. Customer Defined Item

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. Item Measurements

This is an item in which it is necessary to specify one or more measurements as part of the descriptive specification of the item. Other Item Details

For an 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 Price, in which case it is not specified. This makes a detailed Order Response (complex) necessary [See Order Response (Complex)].

Ordered items may include Hazardous Material items, insofar 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.

5.3.2 Order Response (Simple)

The Order Response (simple) is the means by which the Seller confirms receipt of the Order, indicating commitment to fulfill without change, to the Buyer. The Seller may also inform the Buyer, using this Order Response, that the Order has been rejected.

5.3.3 Order Response (Complex)

The Order Response (complex) is a complete replacement of the Order. 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:

5.3.4 Changing an Order

The Buyer can change an Order, subject to the legal contract or trading partner agreement, by sending an Order Cancellation followed by a new, complete replacement, Order.

Buyers can initiate a change to a previously accepted order. Buyers may change an order for various reasons such as changing the ordered items, quantity, delivery date, ship-to address, etc. Suppliers can accept or reject the change order using the order response document.

Changes by the Seller would be accomplished through the OrderResponse (Complex).

5.3.5 Order Cancellation

At any point of the process, a Buyer can cancel an order sent to a Seller. Legal contracts, trading partner agreements and business rules would restrict at what point a Order Cancellation would 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 a contract formation for business commitments will dictate what if any of these restrictions and/or guidelines will apply.

5.3.6 Despatch Advice

As described in the Order, the Item Identification within each Item Line may be made by the Buyer's, Seller's, Manufacturer's, or Catalogue identification of the item, or by an identification assigned by a Standards organisation. It may also be accompanied by an indication of the Country of Origin for the Item. Indication of the Hazardous nature of the Item, and any relevant information, would be indicated in the Despatch Advice.

The following information may appear in the Despatch Advice:

The Despatch Advice caters for two situations:

Additionally, in either case, the Despatch Advice can advise:

 Note: Item Lines of the Despatch Advice may not correspond one-to-one with Order Item Lines, but each needs to be linked by reference to the Order Item Line Id. The information structure of the Despatch Advice, geared to physical considerations, may result in multiple Despatch Advice Item Lines from one Order Item Line. Equally, partial despatch may result in some Order Item Lines not being matched by any Item Line in a Despatch Advice.

5.3.7 Receipt Advice

The Receipt Advice is sent by the Receiver (Buyer) to the Seller to confirm receipt of items, and is capable of reporting shortages and/or damaged items.

The Receipt Advice caters for two situations. For ease of processing claimed receipt against claimed delivery, it needs to be organised in the same way as the matching Despatch Advice:

The Receipt Advice allows the Receiver to state any shortages from the claimed despatch quantity, to state any quantities rejected for a reason which is given, and also to indicate cancellation of any 'to follow' quantity advised by the Ship From or Seller party.

Note: As presently arranged the Receipt Line only allows for one rejection quantity and reason. However, any rejection of quantities of same item for different reasons could be achieved by subdividing the Receipt Line so that there are multiple Receipt Lines to one Despatch Line. (How sophisticated, or precise, do you want the reason for rejection to be? Advising the supplier over the phone is generally more expressive than an electronic message!)

5.3.8  Invoice

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:

The invoice only contains the information that is necessary for invoicing purposes. It does not re-iterate information already established in the Order, Order Response (complex), Despatch Advice, or Receipt Advice that is not necessary when invoicing. The Invoice refers to the Order, Order Response (complex), Despatch Advice or Receipt Advice by the Identifier of those documents.

Taxation on the Invoice allows for Compound Taxes, the sequence of calculation 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:

The present Invoice does not cover Debit and Credit Notes. Nor does the cycle include a Customer Account Statement that summarises Invoices, Credit Notes and Debit Notes to be paid. Invoice Item Line

Each Invoice Item Line refers to the related Order Item Line and may refer to the Despatch Advice Item Line and/or Receipt Advice Item Line.


6 UBL Component Library

6.1 Description

The UBL Library is a collection of re-usable XML Schema [XSD1][XSD2] components that are assembled to create business document definitions.

The non-normative UBL document models contains enough meta-data to allow the automatic generation of XML Schemas based on the UBL Naming and Design Rules.

7 UBL Document Schemas

7.1 Introduction

The ultimate artifacts for the UBL Library are the XML Schemas themselves. These represent the physical implementation of the logical UBL models and are the normative version of the UBL Library.

7.2 XSD Schemas

Normative XSD schemas for the UBL documents and core component types are referenced through the identifiers below.

All  Basic Business Information Entities are expressed as Core Component Types [CCTS] as defined in the schema for UBL Core Component Types:
All  Aggregate Business Information Entities are expressed as complex data types as defined in the schema UBL Re-usable Component Library:
This schema references the UBL Core Component Types.
All  Business Document Definitions are defined in their individual schemas.  These reference the two proceeding schemas:
UBL Order
UBL Order Response (Simple)
UBL Order Response (Complex)
UBL Order Cancellation
UBL Despatch Advice
UBL Receipt Advice
UBL Invoice

Annex A The UBL Library Methodology (informative)



This annex describes the methodology used to identify and define the UBL library content.

The UBL Library was developed as business information entities (BIEs) expressed as a conceptual model.  These are then assembled into hierarchical document structures and transformed using the UBL Naming and Design rules into XML Schema syntax. 

Business Information Entities are Core Components of information used in a specific context [CCTS]. 

UBL assumes each core component has neutral context, or is a de-contextualized BIE.  We can say that a Core Component is a BIE without any context. For example, when we identified the BIE ShippingContact and OrderContact, we also identified that these were two different contexts for a Contact. This meant that we had also identified a de-contextualized BIE called Contact.  By doing this we avoid the need to define the ‘core’ components separately, they are just BIEs that can be used without any context. 

It is our intention to submit all de-contextualized BIEs as candidate Core Components to the relevant UN/CEFACT group as soon as possible.

The UBL conceptual model helps analysts, modelers, domain experts, and others better understand the Library.  This formal and pragmatic approach to library development based on analysis and design techniques we call “Document Engineering".

To promote rapid and widespread adoption, UBL has been developed to allow its workload to be distributed to sub-groups and industry verticals.  This requires a formalization of the approach UBL takes to identifying and describing the content of its library.  To this end the set of processes, notations and UBL meta-model have been defined in such a way that they can be used by a broad range of interested parties to understand, refine and extend the UBL Library and to develop models for their specific business contexts.

To synthesize a range of established vocabularies in both the XML and EDI worlds, this approach also includes explicit steps to identify and reuse design patterns and other artifacts of prior modeling efforts.

A.2 Identifying Content Components

Content components can be identified at three levels:

  1. "Atomic" components that hold individual pieces of information and that are typically represented by primitive data types (e.g., "string," "Boolean," "date") or datatypes readily derived from these.
  2. "Aggregate" components that hold logically related groups of atomic components and sub-aggregates.
  3. "Document" components that assemble atomic and aggregate components to form a self-contained logical unit of work; the clearest examples are transactional messages within a business process. The business process context provides the requirements for which documents are to be assembled.

The hardest level at which to identify good components is at the aggregate level. To do this on an ad hoc and intuitive basis might not identify the optimal patterns for re-use. For example, it might "sound right" to group Name, Address and DateOfBirth into an aggregate component of Person. But what is it about the associations among these three components that makes them into a good aggregate?

The answer comes from conventional data modeling practice, which includes formal rules for designing logical structures and establishing what data analysts call functional dependencies in order to create modular and self-contained groups that lend themselves naturally to re-use. Such grouping are referred to here as "containers".

Analysis has identified three types of containers that are relevant to the design of UBL:

List containers provide a wrapper around sets of repeated data structures with differing values.  They are, "containers of a series of like elements".  For example Line Items in an Order; each Line Item has the same structure, such as item number, description, quantity, etc, and there can be many Line Item occurrences. 

The list container serves to signal the bounds of the list for processing and display purposes. The criteria for list containership in such cases is technical rather than semantic. Whenever a data element is defined as repeatable in the logical model, it is possible to wrap it in list container. 

We refer to these lists of repeated elements as ‘List’ containers.

  • Presentational Containers

Presentational containers such as Header and Summary echo the structure of traditional printed documents. Their use may be to simplify the processing required to display documents for human presentation. In most cases, they add no semantic value.

Most common in any document are containers that wrap elements having an apparent logical connection to each other.  These are ‘Grouped Element’ containers. 

Identifying logical groups allows us to minimize redundancy, localize dependencies, and ensure that information can be maintained in logical sets that reflect the constraints of the real world.

While the identification of logical groups cn be done intuitively maximizes re-usability of common patterns demands a more formal and consistent approach for grouping elements. Data normalization provides such an approach.

A.3 Functional Dependency and Normalization

If the value of one component changes when another component's value changes, then the former is said to be functionally dependent on the latter. For example, each Person we identify is associated with a different Address and DateOfBirth because the values of each of these components functionally depend on the identity of the Person in question.

Technically, this can be defined as :

"Given an ABIE, called E (e.g. Person), the BIE called Y (e.g. DateofBirth) of E is functionally dependent on the BIE called X (e.g. Name) of E if, and only if, whenever two instances of E agree on their X-value, they also agree on their Y-value."

The use a formal technique for identifying and defining these dependencies is known as normalization. Normalization is a series of analytic steps that:

  1. Ensures that all data elements in a group are discrete, i.e., can only take a single value. This means we won't find lists of repeating values in any logical group.
  2. Establishes the primary identifier of each logical group.
  3. Aggregates groups of components that are fully dependent on each value of the primary identifier, i.e., for each instance of the set.
  4. Ensures that all members apart from the primary identifier are independent of one another.

Normalization yields models that describe the network of associations between logical groups of components in optimal ways that minimize redundancy and prevent inadvertent errors or information loss when components are added or deleted. These models are sometimes referred to as Entity-Attribute-Relationship (EAR) models and can also be presented using the UML's Class Diagram notation [UML].

For example, an Order may contain many Products (such as seen in a PurchaseOrder document) or a Product may be on many Orders (such as seen in a SalesReport). Normalization introduces a OrderLine component to reconcile these two views.

UBL has developed a normalized model for objects in the trade procurement business context.  This model is represented by both a spreadsheet and UML Class and Dependency Diagrams and is provided as Annex B in this specification.

A.4 Assembling Hierarchical Document Models

Two-way association such as the one between Product and Order are common in normalized data models and reflect the complex network or web of associations that exist in the real world. The ontology they describe provides great flexibility in the way we can maintain our information.

But, in data exchange information flexibility amounts to ambiguity. We do not want to show all the associations among the information components, only those that are relevant to the business context. This context-specificity is best achieved by creating (or assembling) a hierarchical view out of the relational representation. Hierarchical views introduce grouped element containers that impose a particular interpretation on the information to be exchanged.

Multiple hierarchical views can be created from the same normalized model, as seen with Order and Product (PurchaseOrder vs SalesReport). To create a schema for a PurchaseOrder document type, we would start at Order and list all LineItems and their associated Products. If we wanted a SalesReport document type schema, we would start at Product and list all LineItems and their associated Order. The contrasting document schemas reuse the same components but assemble them in two different container structures, one the inverse of the other.

It is at this stage that the many-to-many and bi-directional associations of the normalized model are reconciled into one-to-many, uni-directional pathways.

The hierarchical view enforces integrity rules and resolves ambiguity in the meaning of the data. What we are saying when we assemble a hierarchical view is "we want to emphasize one context in which you are to understand the data this way." .

Once it is assembled by following a uni-directional path through the normalized model, the hierarchical document model can be directly implemented as an XML schema. This document schema need not show all components and their possible assocations as described in the normalized model, only the ones pertinent to the business context. Put another way, this means that logical components are patterns that can be re-used by assembling them into document schemas based on the context of their use.

UBL provides XML Schemas for several documents used in the trade procurement business context.  The hierrarchical models used in constructing each Schema is represented by both a spreadsheet and UML Class and Dependency Diagrams.  We have found that the combination of these presentation forms is necessary to give a complete functional view of the model.  In addtion, all sub-components of each document type have been consolidated into a shared library to facilitate re-use of common patterns. 

These models are provided as Annex C of this specification.

  The overall UBL design approach can be summarised in the following illustration.


A. 5 The Role of Context

Context is the business environment within which something exists or takes place.  Recognition of context is an important factor in promoting the re-use of common patterns using customized refinements.  Where we have similar circumstances or events, we can use similar patterns of components.

The business context and associated rules assumed by the current work of UBL is described in Section 5 of this specification.  A more formalised approach for assembling UBL Schemas based on the CCTS Context Methodology[CCTS] is scheduled for development as UBL Part 3: Context Methodology.


Annex B UBL Normalized Data Model (informative)

B.1 Introduction

The normalized data model describes the Object Classes, Properties and Associations involved in a general trade procurement process, as defined by Section 5 of this Specification.

This data model is presented in both spreadsheet form and  graphically as both a Class diagram and a Dependency diagram.

Note that this model does represent any specific document type.  It is a conceptual view of all the necessary information components involved in any of the UBL document types.  All the current UBL document types were derived using object classes and associations taken from this model.

B.2 Spreadsheet

The current spreadsheet matrix used by UBL has proven the most versatile and manageable in developing a logical model of the UBL Library. However, we have also found it useful to have a view that encapsulates the big picture of the structure of UBL. Therefore, we have included a graphical notation in the form of UML Class Diagrams [UML]. Such a notation provides a top-level, exploding view.

The spreadsheet for the normalized data model is referenced through


B.3 UML Diagrams

The Class Diagram for the normalized data model is referenced through
The Dependency Diagram for the normalized data model is referenced through

Annex C UBL Document Descriptions (informative)

C.1 Introduction

The following non-normative UBL document models contain the meta-data to allow the automatic generation of XML Schemas[XSD1][XSD2] based on the UBL Naming and Design Rules[NDR].  The final artifacts for the UBL Library are the XML Schemas themselves given in section 7 of this specification. These schemas represent the physical implementation of the following logical UBL models and are the only normative version of the UBL Library.

C.2 Library Spreadsheet

The spreadsheet for the component library is referenced through
UBL Re-usable Components

C.3 Document Spreadsheets

Spreadsheets for each of the UBL document types are referenced through the identifiers below.

UBL Order
UBL Order Response
UBL Simple Order Response
UBL Order Cancellation
UBL Despatch Advice
UBL Receipt Advice
UBL Invoice

C.4 UML Class Diagrams

Class diagrams for the UBL documents are referenced through the identifiers below.

UBL Order
UBL Order Response
UBL Simple Order Response
UBL Order Cancellation
UBL Despatch Advice
UBL Receipt Advice
UBL Invoice


Annex D UBL Reference Models (informative)

D.1 Introduction

Note: This section is a placeholder for materials that will be supplied in the final specification. In the current review cycle, they are scheduled for release after the ASN.1 team processes the normative materials given above. When available, those materials will be found in a supplementary package linked from the UBL Library Content Subcommittee portal at http://oasis-open.org/committees/ubl/lcsc/.

D.2 Non-Normative References

[ASN.1] Abstract Syntax Notation number 1, W3C Recommendation 15 October 2001
[XSL-FO] Extensible Stylesheet Language Version 1.0, W3C Recommendation 15 October 2001
[RELAX NG]  RELAX NG Specification, OASIS Committee Specification 3 December 2001

D.3 XSL-FO Stylesheets

XSL-FO[XSL-FO] stylesheets for the UBL documents are referenced through the identifiers below.

UBL Order
UBL Order Response
UBL Simple Order Response
UBL Order Cancellation
UBL Despatch Advice
UBL Receipt Advice
UBL Invoice
D.3 ASN.1 schema
An ASN.1 schema for the component library is referenced through
[Link to the ASN.1 equivalent of the component library goes here.][is this document actually going to exist???]

ASN.1 schemas for the UBL documents are referenced through the identifiers below.

UBL Order
UBL Order Response
UBL Simple Order Response
UBL Order Cancellation
UBL Despatch Advice
UBL Receipt Advice
UBL Invoice

D.4 RELAX NG Schemas

RELAX NG schemas for the UBL documents are referenced through the identifiers below.

UBL Order
UBL Order Response
UBL Simple Order Response
UBL Order Cancellation
UBL Despatch Advice
UBL Receipt Advice
UBL Invoice


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC