Thanks for the feedback.
I think that the point of the discussion of “current state”
was that the rules cannot be implemented without knowledge of the state as
implied by other messages, or if you prefer they require access to information outside
of the message being processed. Processing the same message may result in
different results depending on the history of other messages. (This is “stateful”
processing, however the state is maintained). In contrast, other
validation rules are “stateless”, in the sense that they always
give the same result no matter what other messages have preceded them.
From: mtf@xxxxxxxx
[mailto:mtf@xxxxxxxx] On Behalf Of matthew.d.rawlings@xxxxxxxxxxxx
Sent: Friday, March 28, 2008 2:08 PM
To: mtf@xxxxxxxx
Subject: Re: MTF minutes, March 28, 2008
I am sorry I
couldn't attend, especially as Contract messaging constraints were discussed.
The key point is that it doesn't require any particular implementation, but
does state clearly what is required. Writing as rules means no knowledge of
'current state' is required as the rules only ever refer to the public message
content. Implementers can process 'current state' however they need to because
the rules don't use it.
Votes below:
1. one for each
2a. yes, but
you must also state the correlation function as per the Coord request of MTF
2b. yes
2c. yes
Matthew
Rawlings
+44 7917 596 827
|
"Brian
Lynn" <brian.lynn@xxxxxxxxxxxxxxxxxxx>
Sent by: mtf@xxxxxxxx
28/03/2008
17:30
|
Please respond to
mtf@xxxxxxxx
|
|
|
To
|
<mtf@xxxxxxxx>
|
|
cc
|
|
|
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 for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data and
other information are not warranted as to completeness or accuracy and are
subject to change without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and
affiliates. This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure under
applicable law. If you are not the intended recipient, you are hereby notified
that any disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this
transmission and any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it is virus
free and no responsibility is accepted by JPMorgan Chase & Co., its
subsidiaries and affiliates, as applicable, for any loss or damage arising in
any way from its use. If you received this transmission in error, please
immediately contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you. Please refer to
http://www.jpmorgan.com/pages/disclosures for disclosures relating to UK legal
entities.