OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


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


Revised proposal.

 

Discussion seems to have died down, so let me see if I can draw everything together. If thie proposal now seems complete then I will take it back to the UBL Comment list.

 

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

 

On Tuesday, 27 August 2019 11:52:46 BST David Goodenough 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





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