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] UBL 2.3 UBL-CommonAgregateComponents-2.3.xsd

Thank you for this comment, David.

We will prepare a formal response as required by OASIS process.

In the meantime, I draw your attention to the minutes of our face-to-face meeting in Australia, January 2018, where the topic of extension points first was raised for UBL 2.3:


The action item was followed up on and test schemas were produced for the community to try:


Feedback was positive:


And this approach was approved in our face-to-face meeting in the Netherlands:


Accordingly, the OASIS Business Document Naming and Design Rules (BDNDR) have been updated pending feedback from the public review of UBL:


I mention this for the benefit of readers of your comment in light of the time it will take for our response. This UBL Comment list is not an appropriate forum for open discussion. We will prepare a formal response to your emailed comment at a future date. I won't take the time today to respond to the individual points that you raise. My objective today is to inform you that the change was not made frivolously, but in response to identified user input.

You may wish to bring the topic up for open discussion in UBL-Dev where there may be feedback from others.

. . . . . . . Ken

At 2019-08-22 10:58 +0000, David Goodenough wrote:

Looking further through the XSD files I see that ext:UBLExtensions has been added all over the place in the cac: definitions.

I have to say I think this is a bad move.

This comes back to the argument that I have raised before. Are you producing a Private Business Language Framework, or a Universal Business Language.

If it is the former, then ext:UBLExtensions makes sense, it corrals the extensions into defined place, and gives the extension a name which makes policing name spaces much easier. For businesses who want to send data built with a private pre-agreed "version" of UBL this makes a lot of sense.

However if UBL is to be genuinely universal it creates some real problems. These documents are legal documents, defining the interaction between businesses, and ext:UBLExtensions really have no place here at all. A generic client will have to ignore them and thus the receiver of the documents will be neither see nor be able to respond to the data encoded in these extensions - unless you are expecting a non-technical business person to read and write their own XML streams? And even if they can read them as XML, will then understand them? If they have been defined by some large company (and it will typically be large companies that do this) and they are simple presented as a fait-acompli (sorry if that is miss-spelt) what are they to do.

If they are simply ignored by generic code, then we have to recall once again that these are legal documents. This is the equivalent of small print printed in such a small font that you can not read it, or worse written in invisible ink that only those in the know (and with the right reagent) can find and read. Fortunately at least in the UK this kind of clause will be thrown out as an "Unfair contract clause" by a reasonable judge, but should it really be necessary to go to court?

What is worse is that you say that these extensions are "sometimes needed to satisfy legal requirements". How can it be right to have something that is not defined and therefore unreadable to users of generic code which is legally required? This section should really read something like:-

"Nothing of legal significance should ever be encoded in a ext:UBLExtension unless that extension is part of the UBL standard or is the subject of a non-UBL private agreement between the two parties which includes the provision of software capable of interpreting and responding to any such data and a formally written specification of the extension. Further it should be assumed that without such a prior agreement the recipient will be unable to view or respond to any such extension"

I am also not sure quite how I would encode in the DigitalCapabilities and DigitalAgreement documents the list of extensions that we have both agreed to accept. If there is no such mechanism then one is urgently needed. The generic code could then simply enforce an empty list of extensions.

In the early days, UBL was functionally incomplete, and so extensions were necessary, but now that functional completeness is for most cases here they really should be deprecated. This will also highlight any areas that need improvement so that they are publicly and properly defined.

Even as process extensions, so nothing of legal importance, this mechanism is of no real use if the recipient can not read or respond to them.

The one exception to this is standardized extensions, such as the Digital Signature extension. While it would be better to have is as part of the regular datastream, the fact that is is defined in the standards document removes it from this discussion.


On Wednesday, 21 August 2019 15:50:40 BST David Goodenough wrote:

In the definition of CustomsDeclaration starting at line 11146 there is a field (ext:UBLExtensions at line 11159) which does not appear in the .html files. Normally this would only be in a top level document rather than as here in a sub-component.

Is this intended?


Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/o/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @ US$45 (5 hours free) |

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