|Subject:||Re: [ubl] Payment Means cardinality in Order Response|
|From:||John Larmouth (j.la...@salford.ac.uk)|
|Date:||Jun 28, 2007 2:01:13 am|
Tim et al,
I am not taking any view on the proposed change, but just want to caution against use of the unqualified term "backwards compatible".
NO-ONE NEED REPLY TO THIS MESSAGE - I AM NOT WANTING TO START A FLAME. IT IS JUST AN ACADEMIC COMMENT.
In this case, the change is from a version A spec saying 0..1 to a version B spec saying 0..many. This means that:
a) Any document conforming to version A conforms to version B;
b) Any system set up to generate a version A document will continue to interwork with a system set up to read and process a version B document;
c) Any system set up to generate a version B document will *fail* to interwork with systems expecting a version A document, for any documents that it generates outside of 0..1.
This is, of course, quite obvious!
There is, however, the additional question of what the version A spec said that implementations should do with unexpected additional material (extensibility). If the version A spec said "If you are expecting 0..1 and you get more than one, process the one you have and give a silent warning", then you know what a version A system will do when hit with a document that conforms to version B but not to version A, and that can be noted in the version B spec. If that statement is *not* present in version A, then you are left guessing on what might happen - perhaps total rejection of the entire document.
It is always best to specify in version A what is to be done with "illegal" documents that are in various senses an "extension" of version A, but people rarely bother to think about doing that - they are too busy getting version A right! It is encouraged in ASN.1 (with explicit notation) to make such provision where there are constraints that might be relaxed in a future version (such as 0..1, or addition of further elements to a sequence), but I am not sure (without checking) whether any provision was made in version A of UBL.
But coming back to my main thread: It is generally better to say that "the version B spec permits all of the documents allowed by version A, but also permits other documents that version A implementations will neither generate nor be able to process". This is more verbose than use of the term "backwards compatible", but is more explicit and clearer.
If there *was* extensibility provision in version A, then you can be more explicit and say "the version B spec permits documents that have additional information to the version A specification; version A implementations will process the information that conforms to the version A specification but will ignore the additional version B information; users of version B should be aware of this limitation."
Again, depending on what was said in version A about the actions to be taken on an extended document (eg "Process version A stuff but send a warning back to the originator about unprocessed material", then the situation in version B becomes much clearer, and the version B spec needs to consider what to do when such a warning comes back. You can see that this gets into a rather tangled loop!
Best advice is:
a) Do as much as you can in a version A spec to support likely (but unknown) version B extensions in a predictable manner (failing that, get stuff into version B that relates to a future version C).
b) Spell out in version B what will happen when trying to interwork with a version A implementation.
Sorry this is a long mail, but making provision in version A for a future version B (or if you forgot to do that, making provision in version B for a future version C) has long been a hobby-horse of mine.
Tim McGrath wrote:
If you are proposing changing the cardinality from 0..1 to 0..many then I would say this is backward compatible and could be a candidate for UBL 2.1.
An instance of of UBL 2.0 OrderResponse wold still be valid under 2.1 with the extended cardinality.
Have you added this to the issues list?
To view the issues list, the URL is:
To add a new issue the form is available at:
The login is 'ubl' and password is 'issues123'.
Greetings UBL TC
As pointed out to me by Luca Reginato in Italy, we have an inconsistency between the document types in that in most of them PaymentMeans has minimum occurance 0 and maximum occurance unbounded, which is great as PaymentDueDate can be automated even when there are multiple payment due dates by using multiple PaymentMeans occurances. So far so good. However it is quite a general requirement to use the OrderResponse document as a key document (usually calling it 'order confirmation' or 'order acknowledgement') as with what is called 'punch out' and similar common practises. In such cases the OrderResponse is the primary document from the seller (or seller's agent) and so it there is a strong requirement to include here the payment information such as a Payment Due Date or set of Payment Due Dates. The inconsistency is that in UBL 2.0, although the need for such payment requirement information is acknowledge by the inclusion of PaymentMeans, it is only, in the OrderResponse with the allowance of zero or one occurances (hence only a single payment due date at most).
I do accept that fixing this would be quite a challenge as it may involve a backwards compatibility issue. Maybe there is a way to fix it by creating a new ASBIE and ABIE which has multiple occurances and appending it to the Order Response. Otherwise it would seem implementers making primary use of the OrderResponse in this way have to 1. create their own extension which reduces the opportunities for interoperability or 2. use a document such as Invoice in situations where this is otherwise deemed as unnecessary (and therefore more expense is imposed which doesn't necessarily bring a proportional return on investment perhaps) or 3. do without the automation of the payment due dates and just use a note or description. I think 3. is unsatisfactory as it should be a major benefit of using UBL that payments can be fully automated as part of use of implementing electronic procurement with UBL.
Partner SystML, http://www.systml.co.uk Tel: +44 (0) 117 9541606
--No virus found in this incoming message. Checked by AVG Free Edition.Version: 7.5.476 / Virus Database: 269.9.10/873 - Release Date: 26/06/2007 11:54 PM
-- Prof John Larmouth Larmouth T&PDS Ltd (Training and Protocol Development Services Ltd) 1 Blueberry Road Bowdon j.la...@btinternet.com Cheshire WA14 3LS England Tel: +44 161 408 3695 Fax: +44 161 928 8069