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: