Re: [ubl-dev] ubiquitous UBLExtensions: a proposal

On Tue, Aug 27, 2019 at 6:52 AM David Goodenough <david.goodenough@broadwellmanor.co.uk> wrote:

Following on from my comments on the UBL 2.3 draft I would like to offer a draft proposal which I think might solve the problem.

Â

I appreciate that UBL is not a recognised international standard for legal documents, but it does replace what would otherwise be legal documents and for ease of end user comprehension it would be easier if the same basic rules applied to paper and electronic documents. In addition it seems a reasonably aspiration for UBL documents to be recognised as the same legal status as paper ones.

Â

The problem arises because a generic client will not be able to read and therefore present to the user or to an API into other systems items that are encoded in the UBL extension for which it has no support. The extensions are therefore hidden from the user which is legally undesirable. Note that the Signature extension as described in the UBL documentation is not included in this discussion as it is well defined and publicly documented.

Â

In the notes below upper cased words such as MUST or SHOULD are intended to be interpreted following the notes in IETF RFC 2119.

Â

The proposed solution to this problem involves adding a single element to DigitalCapability and DigitalAgreement documents which describes the permitted extensions that can be used (and where they can be used) in document exchanges sanctioned by this DigitalAgreement. This element is tentatively called PermittedExtension, and is minOccurs="0" maxOccurs="unbounded". If there is no PermittedExtension object in the final DigitalAgreement then any document that is received which contains a UBLExtensions clause other than the Signature extension document in the UBL 2.3 documentation MUST be rejected by the receiver. This maintains the current behaviour on all but the document level tags. Whether it should apply immediately to the existing document level tags is an open question, my instinct is that it should as it will be difficult to increase the enforcement later.

Â

I would suggest, but I have only given 18 hours thought to this, that these PermittedExtension objects could be included in the DigitalProcess or DigitalCollaboration objects as they are they are about a conversation and the same rules should apply to both ends of the conversation.

Â

A PermittedExtension object MUST contain an ID which defines the name of this extension and the controlling agency. It MUST also include a URI for the schema of the extension and a URI for a narrative document describing the meaning of the extension. Both these URIs and the documents they point at MUST be publicly and freely accessible and usable - the rational for this is that if subsequent inspections of such documents by outside bodies (be they governmental, trade assurance schemes, or such as auditors ) must be possible without let or hindrance. A PermittedExtension MUST also include a minimum and maximum version number of the extension, so that the handling of the corresponding UBLExtension (I hope these are versioned if not they need to be) can be ensured. Finally the PermittedExtension object MUST contain a list of UBL objects within which the extension can be used. It might be useful for an extension to be used on for instance all Party objects where ever they are used, but it might be that they should only be used in a say DespatchAdvice object. Do we need a UBL version check in here as well?

Â

If a receiver's software receives a DigitalCapability or draft DigitalAgreement (the one in response to a DigitalCapability) which requests a PermittedExtension that it is not equipped to handle the document MUST be rejected with an ApplicationResponse including the PermittedExtension that can not be accepted. The sender's system MAY then amend the DC or DA to remove the unacceptable PermittedExtension or it MAY terminate the conversation. The sender's system SHOULD NOT re-send a refused PermittedExtension unless the receiver's system has been updated to accept it. Coordinating this update notification is outside the scope of UBL communications.

Â

If a receiver's software receive a UBL document which contains one or more UBLExtension objects that are not included in the list of PermittedExtension objects in the current DigitalAgreement the software MUST reject the document with an ApplicationResponse including the un-permitted UBLExtension.

Â

One question that worries me is how we do schema validation in this environment. Doing schema validation is desirable as it makes the code easier to write if the datastream is known to obey the schema, but I am unsure (I simply have not had time to look) whether schema validating XML loaders have the ability to merge schemas in this fashion. This is an area that needs further research.

Â

I hope that this document is a useful starting point (along with my original objection) to resolve this problem. My preference would be either to define and include a PermittedExtension like object in 2.3, or if it is to be deferred to 2.4 that the UBLExtension proliferation that occurs in the 2.3 draft be withdrawn until the PermittedExtension functionality can be included.

Â

David

ubl-dev message