[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Payment Means cardinality in Order Response
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]