Re: [ubl] Payment Means cardinality in Order Response

[John Larmouth <j.larmouth@salford.ac.uk>]

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.

John L

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:
>>
>> http://www.eccnet.com/UniversalBusinessList/IssuesList.xml
>>
>> To add a new issue the form is available at:
>>
>> http://www.eccnet.com/UniversalBusinessLanguage/AddIssue.html
>>
>> The login is 'ubl' and password is 'issues123'.
> 
> 
> 
> 
> stephen.green@systml.co.uk wrote:
> 
>> 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.
>>
>> Best regards
>>
>> --Stephen Green
>>
>> Partner
>> SystML, http://www.systml.co.uk
>> Tel: +44 (0) 117 9541606
>>
>> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>>
>>
>>
>>
>>
>>
>>
>> --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.larmouth@btinternet.com
    Cheshire WA14 3LS
    England
    Tel: +44 161 408 3695		Fax: +44 161 928 8069