OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-dev] FW: formalize the collection of files used in a ttrading partner agreement


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 :-)

Fraser.



On 09/08/06, Juerg Tschumperlin <juerg.tschumperlin@minedu.govt.nz> wrote:
> 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
>
>
>
>
>
>
>
>
>
> DISCLAIMER
> This e-mail is intended for the addressee only and may contain information which is subject to legal privilege. The contents are not necessarily the official view or communication of the Ministry of Education. If you are not the intended recipient you must not use, disclose, copy or distribute this e-mail or any information in, or attached to it. If you have received this e-mail in error, please contact the sender immediately or return the original message to the Ministry by e-mail, and destroy any copies. The Ministry does not accept any liability for changes made to this e-mail or attachments after sending.
> All e-mails have been scanned for viruses and content by security software. The Ministry reserves the right to monitor all e-mail communications through its network.
>
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]