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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

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

Subject: Re: [ubl-comment] Invitation to comment on Universal Business Language v2.3 from the UBL TC - ends February 15th



1) In the Invoice definition, InvoiceLine is shown with a type of ASBIE, in the definition of InvoiceLine it is shown as an ABIE. Why the difference?


I also do not understand how having bits of a document that a party can not read can be compatible with the paragraph at the top of page 11 of the PDF UBL manual. Extensions means that UBL documents can not Legally binding business documents on the grounds that you can not assign legal significance to a part of a document that the recipient can not read. It is not just the possibility of misuse that bothers me, it is the entire concept.


2) The point about making the extension definition a defined part of a document is that then a generic program can be used to decide whether this is an acceptable document. I agree that no functionality should be allowed that duplicates existing function, and this is a start, but the question that needs to be answered is "how does a user read a document with extensions he can not read, and how does a generic program notify the user (other than showing them a bit of UBL XML which would be unacceptable) that there is something there that they can not read. Saying that people should define their own object domains keeps the extensions unique, but does nothing to make them readable.


I have already proposed a possible way to define the acceptable extensions should be encoded.


Frankly I believe that extensions other than standardised ones like the cryptographic one should be deprecated, and then removed in a future release. Extensions are an admission of failure, and we should not be planning for failure.


On the subject of the messages referenced in the response my objection, these do not seem to be messages to the only two UBL mailing lists that I am subscribed to (ubl-comment and ubl-development), both of which I have been reading for a while now. Which mailing lists are they on, and where do I sign up to them?


If I had a vote, which I appreciate I do not, I would vote against 2.3 just on the basis of the propagation of extensions.




On Tuesday, 4 February 2020 16:59:29 GMT Kenneth Bengtsson wrote:

Hi David


Thanks for your input. Let me try to clarify:


1) Previous UBL versions only allowed extensions at the document level, which is different from allowing extensions to ABIE elements. Consider for example an invoice with several invoice lines. Previous UBL versions would only allow you to extend the invoice document itself, but not the invoice line ASBIE itself. The following is now possible with UBL 2.3:


Invoice document

- Invoice line 1

- - [Extension with information related to invoice line 1]

- Invoice line 2

- - [Extension with information related to invoice line 2]


There are no changes to this between the first public review and the current public review, except for the clarification in the specification (sections 3.5.1 and 3.5.2). The XML schemas themselves remain unchanged.


Personally I share your concern about possible âmisuseâ of extensions, and I do think it important to emphasize that the extensions are intended for adding information that cannot be expressed using existing UBL vocabulary (i.e. information and elements that were not contemplated within UBL itself). Extensions are not intended for creating alternative ways of conveying information that already has its place in UBL. Weâve tried to clarify this with section 4.7.


2) I believe there is a difference between being âreliantâ on non-UBL documents and being able to make reference to non-UBL documents. Business documents frequently make reference to other documents, and some of those documents are defined elsewhere and fall outside the scope of UBL (contracts and agreements, legal documents, technical drawings, project plans, photographic images, just to name a few). UBL provides mechanisms for making references to such documents, and your vision that agreements should be expressed in a structured and standardized format is excellent. It is certainly what we are working for as well. Specifically for agreements about data model and content requirements (including extensions), UBL has the Profile ID and Customization ID, and 2.2 introduced the Digital Agreement document type. Your suggestions for how these can be improved, as well as for any additional information items and document types we can add will be more than welcome!


Best regards,






From: David Goodenough <david.goodenough@broadwellmanor.co.uk>
Date: Tuesday, February 4, 2020 at 5:56 AM
To: "ubl-comment@lists.oasis-open.org" <ubl-comment@lists.oasis-open.org>
Subject: Re: [ubl-comment] Invitation to comment on Universal Business Language v2.3 from the UBL TC - ends February 15th


Looking at this list I am royally confused.


1) The original 2.3 proposal that I reacted to was to add extensions to ALL compound UBL objects, but 3.5.2 has been changed to say only ABIE objects (i.e. root objects) can have extensions, which is what previous versions had. The discussion says that effectively my objection was rejected, but the text says that UBL has reverted to pre-2.3 behaviour. While I don't like extensions at any level, the pre-2.3 extensions are already there and given the wish to remain backward compatible it would be difficult to remove them.


2) The point of my second object was that the agreement process for allowing extensions should have a digital representation that was part of the exchanged datastreams. Having it in separate unstructured documents, phone calls, post it notes or whatever really misses the point. UBL should be self contained, and not reliant on non-UBL documents!




On Monday, 3 February 2020 19:02:00 GMT Paul Knight wrote:

Hi David,


I'm not at all involved in the technical work of UBL, so this may not be the specific item you are asking about, but I see that two issues you had raised are addressed as the first two entries in the "comment resolution log" prepared by the UBL TC after the first public review. It appears that some changes were made based on your comments.

If you have not already seen that, it may be helpful.


By the way, thanks very much for your interest and comments.


This is cited from the announcement, at [2]:


[2]  Previous public reviews:
- 30-day public review: 20 August 2019
- Comment resolution log:


Best regards,



On Mon, Feb 3, 2020 at 1:14 PM David Goodenough <david.goodenough@broadwellmanor.co.uk> wrote:

By the look of it the objection to universal extensions has been accepted, which if it is true is good news.


As a comment on the process that lead to that acceptance, it is strange that a formally raised (at least I think I raised it formally) matter such as this has never actually been responded to. No documentation seems to exist (at least that I have come across) about the discussion that happened as a result of my observations. It is quite possible I am simply not looking in the right place - if so please can someone tell me where to look.




On Monday, 3 February 2020 16:10:31 GMT Paul Knight wrote:

Hi David and all,


While not a "list of changes", there is an accompanying "diff" file noted in the announcement, at footnote [3].  In case you missed that in the original announcement, I hope it is helpful.


[3] Red-lined version:


Best regards,



On Sat, Feb 1, 2020 at 1:44 PM David Goodenough <david.goodenough@broadwellmanor.co.uk> wrote:

Is there a list of changes since the first public review? A quick look did not reveal one, but I may have missed it.




On Friday, 31 January 2020 17:58:58 GMT Paul Knight wrote:

OASIS Members and other interested parties,

We are pleased to announce that Universal Business Language Version 2.3 from the UBL TC [1] is now available for public review and comment. This is the second public review for Universal Business Language v2.3.

UBL is the leading interchange format for business documents. It is designed to operate within a standard business framework such as ISO/IEC 15000 (ebXML) to provide a complete, standards-based infrastructure that can extend the benefits of existing EDI systems to businesses of all sizes. The European Commission has declared UBL officially eligible for referencing in tenders from public administrations, and in 2015 UBL was approved as ISO/IEC 19845:2015.

Specifically, UBL provides:
- A suite of structured business objects and their associated semantics expressed as reusable data components and common business documents.
- A library of schemas for reusable data components such as Address, Item, and Payment, the common data elements of everyday business documents.
- A set of 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 generic procurement and transportation contexts.

UBL v2.3 is a minor revision to v2.2 that preserves backwards compatibility with previous v2.# versions. It adds five new document types, bringing the total number of UBL business documents to 86.

The specification documents and related files are available here:

Universal Business Language Version 2.3
Committee Specification Draft 02 / Public Review Draft 02
29 January 2020

Editable source (Authoritative):
Code lists for constraint validation:
Context/value Association files for constraint validation:
Document models of information bundles:
Default validation test environment:
XML examples:
Annotated XSD schemas:
Runtime XSD schemas:

For your convenience, OASIS provides a complete package of the prose specification and related files in a ZIP distribution file. You can download the ZIP file at:

How to Provide Feedback

OASIS and the UBL TC value your feedback. We solicit feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work.

This public review starts 01 February 2020 at 00:00 UTC and ends 15 February 2020 at 11:59 UTC.

This specification was previously submitted for public review [2]. This 15-day review may be limited in scope to changes made from the previous review. Changes are described in the previous comment resolution log [2] and highlighted in a red-lined file included in the package [3].

Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be used by following the instructions on the TC's "Send A Comment" page (https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ubl).

Feedback submitted by TC non-members for this work and for other work of this TC is publicly archived and can be viewed at:

All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with the public review of these works, we call your attention to the OASIS IPR Policy [4] applicable especially [5] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification.

OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work.

Additional information about this specification and the UBL TC may be found on the TC's public home page [1].

========== Additional references:

[1] OASIS Universal Business Language (UBL) TC

[2]  Previous public reviews:
- 30-day public review: 20 August 2019
- Comment resolution log:

[3] Red-lined version:

[4] https://www.oasis-open.org/policies-guidelines/ipr

[5] https://www.oasis-open.org/committees/ubl/ipr.php
RF on Limited Terms Mode

Paul Knight....Document Process Analyst...mobile: +1 781-883-1783

OASIS - Advancing open standards for the information society




Paul Knight....Document Process Analyst...mobile: +1 781-883-1783

OASIS - Advancing open standards for the information society




Paul Knight....Document Process Analyst...mobile: +1 781-883-1783

OASIS - Advancing open standards for the information society


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