[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MTF Vote on messaging options - REMINDER
Brian,
Looks like I missed the deadline, nonetheless for what its worth my votes
on the messaging questions for the MTF are as follows:
(1) First choice: 3 (because 1 message doesn't feel right, and I'm not
sure that 2 messages helps greatly)
Second choice: 2
(2a) yes, subject to clear understanding of what constitutes the "business
object"
(2b) yes, because strong typing doesn't help here
(2c) yes, subject to clear understanding of the common processes & their
applicability to different objects
Best regards,
Harry
|---------------------------------------->
| Internet |
| brian.lynn@xxxxxxxxxxxxxxxxxxx|
| |
| |
| Sent by: mtf@xxxxxxxx |
| |
| 02/04/2008 21:42 |
| |
| |
| Please respond to |
| mtf@xxxxxxxx |
| |
|---------------------------------------->
>---------------------------------------------------------------------------------------------------------------|
| |
| |
| To|
| mtf |
| cc|
| |
| Subject|
| MTF Vote on messaging options - REMINDER |
| |
| |
| |
| |
| |
| |
>---------------------------------------------------------------------------------------------------------------|
(I'm resending this as it didn't get back to me the first time. Apologies
if you see this twice).
As I've received only one vote on the messaging options (possibly due to
mailing list related issues), I'm extending the deadline to COB Thursday.
Reminder -
MTF participants, please vote on the following:
1) Number of messages for new/correct/cancel (1, 2, or 3). Please provide
first and second choice.
2a) correlate messages based on unique business object id (y/n)
2b) combine status return messages (y/n)
2c) combine request messages for same business process on different objects
(y/n)
For those other than Matthew (whose votes I have), if you have already
voted, please resend your vote, as I have not received them.
------------------------------
I had planned to hold my vote until the completion of voting, but as a way
of prompting participation, here are my votes.
1) (Combining messages) - first choice 1, second choice 2.
2) a), b), and c) - yes to all
Brian
-----Original Message-----
From: mtf@xxxxxxxx [mailto:mtf@xxxxxxxx] On Behalf Of Brian Lynn
Sent: Friday, March 28, 2008 1:31 PM
To: mtf@xxxxxxxx
Subject: MTF minutes, March 28, 2008
Attendees
=========
Irina Y., ISDA
Lyteck L, ISDA
Robert S, Brookpath
Brian, GEM
Andrew J, Handcoded
Marc G, ISDA
Harry Mc., BNPP
Jason P, BGI
Henri P, DTCC
Christian N, Message Automation (late)
Regrets
=======
Matthew R., JPM
Vote
----
Due to low attendance from market participants and service providers at the
outset of the meeting, we agreed to hold the vote on messaging options by
email. Please provide your vote to the list by email by COB Tuesday. I
will tabulate the votes and report the results next week.
Please vote on the following:
1) Number of messages for request/correct/cancel
Choices are 1, 2, or 3, as described in this week's MTF meeting invitation.
Please provide both your top choice and your second choice. If none of the
options receives a majority in the first round of voting, the option with
the lowest number of votes will be eliminated. If your top choice is
eliminated on the first round, your second choice will be used on the
second
round. If your top choice is not eliminated in the first round, it will
still be used in the second round.
2) Approval of the following decisions:
a) correlate messages on the same object using a unique business object
identifier (vs. correlation ID or message ID).
b) have a single processing status message with a reason code instead of
ones for each error reason.
c) combine messages so that a single business process on different types of
objects (e.g. confirm trade, admendment, novation, etc.) is supported by a
single message or set of messages, rather than distinct messages per object
type.
Please either vote "yes" (to all) or "no". If you vote "no", please also
indicate whether you vote "yes" or "no" to each subitem (i.e. a, b, and c).
Validation of Matthew's contract message validation rules proposal
==================================================================
We discussed this at some length (in the absence of Matthew), and came to a
number of areas of consensus or where we felt that additional clarity was
required.
1) We liked the use of the validation rule expression syntax for
documenting
these types of rules for processing messages. We felt that these types of
rules would be useful documentation for implementers. There may be some
advantage to this type of rule as opposed to other documentation
mechanisms.
For example, they do not require the specification of a standardized state
model, which could be difficult to get agreement on.
2) We did not feel that these rules were like traditional validation rules,
because these rules require access to the current state of the processing
system (i.e. they are "dynamic" or "state-dependent"). Other validation
rules express constraints about the content of a single message, and can be
applied without consulting other messages. This makes them amenable to
being applied in a stand-alone validation application. The rules in
Matthew's proposal can only be applied with access to a database containing
the current processing state.
For this reason, we felt that these types of rules should be clearly
distinguished from validation rules. They should be associated with the
business process definitions and be termed something like "message
processing" or "request processing" rules, rather than "validation" rules,
for clarity for implementers.
We think it would be beneficial to develop a suite of these rules, and felt
that a quite number of the rules in Matthew's document could be useful as a
starting point for this set.
3) We had questions about what the expected handling of different
severities
would be. For example, would a "Mandatory" rule violation automatically
result in an immediate failure report to the sender, or could it be handled
by a repair function? Different people on the call had different
interpretations of the likely handling of these types of rules.
4) We felt that it was essential that the context of the "collection" of
business objects be defined very clearly for the rules to be clearly
defined. For example, is uniqueness for business object identifiers (e.g.
contract IDs, as listed here) required across all generators of documents,
or only within a single generator? Should a recipient of messages from
multiple sources validate the IDs against IDs submitted by other sources as
well, or must they be kept distinct? If a sender attaches multiple IDs
each
with a different scheme, shouldn't they be checked for uniqueness
including/within the scheme?
5) Can an identifier (e.g. trade identifier, message identifier) ever be
recycled, for example in case of an explicit instruction that the
identifier
was incorrectly assigned? Or, for example, could a message ID be recycled
after, say, a month?
6) It appears that the uniqueness rules apply to all identifiers included
by
the document creator, whether or not they were actually assigned by the
document creator (the contract/header/identifier element can occur multiple
times, and the rule appears to apply to all of the occurrences). This
means
that if a document creator attaches identifiers allocated by another party
to a contract/trade, it will be difficult or impossible to change that
association if in the future a mistake is discovered, since these
identifiers cannot be reused in another contract/trade (without causing a
uniqueness violation). Is it possible to distinguish to which
identifier(s)
the uniqueness constraint should be applied? (Brian suggested this may be
more of a modeling than a validation issue).
7) Since the "identifier" element in contract has some sub-structure (e.g.
versioned and non-versioned variants), it would be useful to have a more
precise definition of the ID matching rules.
Upcoming
========
April 7 - Back to regular time in UK (11 AM NY, 4 PM UK): Results of vote,
continue discussion of object identification (other proposals), review
status.
This communication is confidential, may be privileged and is meant only for the intended recipient. If you are
not the intended recipient, please notify the sender by reply and delete this message from your system. Any
unauthorised dissemination, distribution or copying hereof is prohibited.
BNP Paribas Fund Services UK Limited, BNP Paribas Trust Corporation UK Limited, BNP Paribas UK Limited,
BNP Paribas Commodity Futures Ltd and Investment Fund Services Limited are authorised and regulated by
the Financial Services Authority.
BNP Paribas, BNP Paribas Securities Services and BNP Paribas Private Bank are authorised by the CECEI
and AMF. BNP Paribas London Branch, BNP Paribas Securities Services London Branch and BNP Paribas
Private Bank London Branch are regulated by the Financial Services Authority for the conduct of their UK
business. BNP Paribas Securities Services London Branch is also a member of the London Stock Exchange.