TP Agreements

["Fraser Goffin" <goffinf@xxxxxxxxxxx>]

Another thread that appeared to get lost when the servers died, that I
would like to continue.

Jeurg said :-

>Hi,
>
>Ken Holman and I were discussing how trading partners can formalize the 
>collection of files used in an agreement to interchange an XML instance 
>that is based on a unambiguous collection of XML schema file versions, 
>genericode file versions, context association file versions, business rule 
>file versions etc.
>
>We look forward to your practices and thoughts on this.

>Regards Juerg


Jeurg,

What assertions or conclusions did you reach on how best to ensure
that both parties are synchronised in terms of the versions of
messages that they each support.

Given that one or both parties may support multiple versions does it
matter (other than for explicit private interactions) whether there is
apriori knowledge of what any particular party may support so long as
that version can be identified as part of the message meta-data
sent/received ?

We have some issues where, when we *initiate* a conversation with a
number of  parties (in our case for something like a renewal invite
for an insurance policy) we *may* not know precisely which versions of
the renewal invite message that they each support. What thoughts have
you on this matter ?

Some suggest that (certainly from a minor revision point of view), we
should be aiming to create implementations that are *tolerant* to
mis-matched [minor]versions. What do you think ?

Many regard that the implementation of a request/reply pattern should
maintain a *matched* pair of messages, that is, the version of the
response is the version counterpart of the original request (even when
the schema which describe these two messages are at different versions
individually) ?

Sometimes (actually quite often) we have to deal with *mid term
changes* to policies (e.g. a change of address). When this occurs the
business rule is that message for the change MUST be the *same*
version as the original 'request for quotation' perhaps received some
months earlier (this is so premium calculations for the change are
based on the original rules whilst that policy is in force - dont ask
me why !). The problem this gives us is knowing what that original
version was once the message has been consumed and the data transfered
onto back-end databases. I guess we will need to keep the version
meta-data from the original message somewhere right ?

Versioning is a real big issue in my world right now :-(, so any tips
on keeping it simple, greatly appreciated :-)

Regards


Fraser.