MTF minutes, March 28, 2008

["Brian Lynn" <brian.lynn@xxxxxxxxxxxxxxxxxxx>]

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.