[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] ubiquitous UBLExtensions: a proposal
|
Hi David Thank you for your valuable comments and input. I will try to clarify the extensions in the UBL 2.3 draft and in general: UBL is recognized as an international standard for business documents (ISO/IEC 19845). Whether a
business document is also a âlegal documentâ depends entirely on your definition of âlegal documentsâ as well as of the laws and practices of the specific jurisdiction where you would want your UBL document to have the value of a legal instrument. In the UBL TC we obviously do not try to define legal practices and requirements. We define a technical format and vocabulary, which in many cases is adopted as de jure standard in individual jurisdictions, and in other cases simply adopted
as de facto standard for exchanging information between two or many trading partners. Whether used as a de jure or as a de facto standard, there may be situations where a UBL user or a group of users has the need to express information in a UBL document which cannot be expressed using the existing UBL library. This could
be information so specific to the systems and circumstances of the user that we didnât find any reason to include it UBL. Take a look at the Colombian e-invoice for example. Colombia is an invoice clearing country, meaning that before an invoice becomes a legal fiscal instrument, a supplier must first send it to the tax administrator to obtain a permission,
and only then can he send the invoice to the buyer. The Colombian e-invoice contains all the usual information items that you would expect to find in an invoice (buyer party, supplier party, tax and VAT, line items, prices, and so on), all expressed as UBL,
and it also contains information that is specific to the Colombian tax administratorâs issue approval process - reference to a previously obtained approval from the tax administrator for the issuer to use a certain range of invoice numbers for example. In UBL we donât have a specific field where one can express the Colombian tax administratorâs authorization number that approves that a company can issue invoices numbered in the range 100 to 200, and it probably isnât very relevant to
anyone except the Colombian tax administrator. So they have made a UBL extension to express that information. If you as a British entity were to receive an invoice from a Colombian supplier, you could safely ignore the information in the extension because
the information you would usually need from the invoice is expressed in the âcommonâ UBL structure. The intention of the UBL extensions is to allow implementors and users to express information that they canât express using existing UBL vocabulary. Itâs a flexibility that allows UBL to be used as a de facto or de jure standard even in
situations where there are requirements not foreseen by the UBL TC or so specific that they donât âbelongâ in a global standard. In previous versions, these extensions could only be included at document level. But what if a user needs to include such information
at line level? This is what we are trying to accommodate for in UBL 2.3. Notwithstanding the above, I do understand and share your concern about extensions. They shouldnât be misused and they shouldnât be used to express information that is already contained and standardized in the UBL vocabulary itself. Perhaps
we can emphasize this in the prose specification. Best regards, Kenneth From: David Goodenough <david.goodenough@broadwellmanor.co.uk> 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]