UBL 2.3 draft UBLExtensions revised proposal

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

Revised proposal.

 

Discussion seems to have died down, so let me see if I can draw everything together.

 

In the notes below upper cased words such as MUST or SHOULD are intended to be

interpreted following the notes in IETF RFC 2119.

 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

While acknowledging that currently UBL is not a definition of legal documents, it would a shame to introduce a feature which meant that it could not be used as such.

 

Extensions have their place, but their use needs to be done in a way that mean that all participants in a document exchange (i.e. those pairs of Partys who have exchanged a DigitalAgreement) can either process or safely ignore any extension that is present in any document they receive.

 

To this end an additional clause is proposed to be added to the DigitalCapability and DigitalAgreement documents in either the DigitalCollaboration or DigitalProcess objects which list those extensions which can be included in the documents and whether they can

be ignored or can be handles at both ends of the exchange.

 

Extensions fall into two groups:-

 

1) Those such as SAP process tags which can safely be ignored if the receiver is unable to handle them. It follows that any extension marked as ignorable MUST NOT contain any legally significant information

 

2) Those that both ends of the exchange are required to be able to understand. The handler(s) for the extensions is best placed to be able to handle the detection of where the extension can and can not be placed, and may reject a document if these placement rules are not followed. So say an Invoice document might require a particular extension, but it might not be allowed on all other documents, or some extension might be legal in some

documents but not be required anywhere.

 

In order to define the list of allowed extensions, for want of a better name an PermittedExtensions tag should be defined (minOccurs="0" maxOccurs="1")

and inside it there should be a set of UBLExtension objects. These MUST have all the attributes that are to be present on the extensions which are to be accepted (see un-attributed extensions below), and in their body there is one required tag (URI) and one optional tag (Ignorable). The URI tag defines a web site visible to both the parties to the exchange which defined what the extension is for and how it should be used. The Ignorable tag has an Indicator within it which defaults to false and says that this tag can

be safely ignored.

 

UBLExtension tags with no attributes are considered to be ignorable, and therefore MUST NOT contain legally significant data. All the example documents provided which included no-attribute UBLExtension tags have no attributes.

 

The use of UBLExtension for Digital Signatures as defined in the UBL documentation is considered a permitted extension

 

When a DigitalCapability or DigitalAgreement with a PermittedExtension tag is received the receiving code MUST check that it can handle the listed extensions, and if there are any it can not is MUST send back an ApplicationResponse rejecting the document, and MUST include a list of the extensions that were requested and can not be handled.

 

When any document is received, if there are UBLExtension objects present they MUST be checked against the most current DigitalAgreement (no agreement implies no permitted extensions) between the parties and if there are UBLExtension objects that are not listed in the PermittedExtensions they this document MUST be rejected with an ApplicationResponse including the offending UBLExtension. The receiving code MUST also check that the UBLExtension being processed is in a correct place, and reject documents where the extension is in the wrong place and documents where this extension is required but missing, again an ApplicationResponse including a list of any offending UBLExtension objects MUST be included.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

 

I hope that the above provides a basis for a controlled use of extensions within UBL. In the absence of such a control, I feel it would be a mistake to include the proliferation of UBLExtension tags proposed in the UBL 2.3 Draft document.

 

David