Minimum Viable Product Lines and how we designed the Universal Business Language

 Minimum Viable Product Lines and how we designed the Universal Business Language (OASIS-open . org UBL)

Minimum Viable Product Lines, MVPL, allows for multiple sets of requirements coded as extensions with a basic common core.  

I happily worked with the designers of the Universal Business Language: An XML format for invoices, orders, delivery advices, and the like, used for electronic business in various parts of the world. We designed it by consensus of technical delegates from various interested countries. We did not give a name to our eventually agreed extension design approach, but it could be called an MVPL approach. It proved to be a challenge to find the best design for how UBL could be truly extensible. 

At first many of us believed the promise of eXtensible Markup Language, XML, that it was truly extensible. Most of us thought this extensibility would come from its schema constraint language called XML Schema Definition language, XSD. The theory was that each discrete data item in the invoice or order document would, by virtue of being written in an XML language, be extensible, by either restricting it or extending it, in variant forms of the invoice or order format. 

XSD did not live up to this hope. We were quickly disappointed in the first version of UBL to find that certain design decisions we had made along the way had precluded the use of the restriction and extension capabilities of the schema language. We needed another way. We eventually adopted an approach very similar to the way software is extended in many applications. We designated one element as an extension point, and designed an extension format which could accommodate custom extensions. All the extensions could be added to the start of the document, without affecting the rest of the document.

In practice it is not completely honest to say an extension does not affect the rest of the document. Care must be taken. An extension that includes something already existing in the main document could have undesirable consequences for those trying to cater for how they receive such a document. For example, does the extension now include monetary amounts which need to be included in the main document monetary totals? Are there now two places where the same data item might be within the extended document? If these contradict, which must be taken as official? If an extension includes data not covered in the main document, what happens if a new version of UBL comes out which includes it? And so on.

The strength of the extensions methodology is that on the whole it allows most use of the main part of the UBL document to keep its integrity. Semantic drift is common with information formats. The system sending the UBL invoice, say, might need to provide some information such as utility usage data, or hours worked, which were not covered in the invoice design for that version of UBL. Some might want to include such data, and be ‘tempted’ to put it in a not entirely appropriate element, thus distorting the meaning of that element. Over time elements might come to be used commonly in ways not intended and contradictory to the official definition of the element. Having an extension point allows data such as utility invoice data or hours worked timesheet data to be included in an invoice in a sensible way, agreed between senders and receivers, without misusing elements of the main standard document or changing the meaning of such elements. 

These are similar principles to those used today in MVPL software architectures. In each case there is a need for good governance, especially during business analysis, but also during software coding. It is a similar discipline to that of a Compliance Office of a company. Somebody needs to ask from day one the necessary questions about whether MVPL rules are being properly applied, and so right through design and coding, and even in day to day use. 

I will let AI write the conclusion.

“In retrospect, the experience of designing UBL demonstrates that true extensibility is less about the technical promise of a language and more about the disciplined application of architectural and governance principles. The extension-point model adopted anticipated what is now recognized as a Minimum Viable Product Line approach: preserving a stable, interoperable core while enabling structured, controlled variation to meet evolving business needs. By separating innovation from standard integrity, UBL was able to support diverse global requirements without fragmenting the standard itself. Ultimately, the success of such approaches depends not only on technical design, but on sustained stewardship, clear governance, and a shared commitment among stakeholders to balance flexibility with consistency.” — ChatGPT