Re: [ubl-comment] UBL 2.3 UBL-CommonAgregateComponents-2.3.xsd

[David Goodenough <david.goodenough@broadwellmanor.co.uk>]

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.

 

David

 

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?

 

David