Matthew –
You certainly have a point. However, the tokens I’m talking
about are actually identifiers (immutable, unique) for someone, just not the
sender.
In any event, the essence of your comment below is essentially
what I’ve proposed in the model that I distributed last week: make a clear
distinction in the schema between identifiers assigned by document creators,
and tokens believed by the document creator to be used by OTHERS to identify
the document. I’ve called those alternate identifiers, but perhaps a different
name is better. I just think that “code” is a bit vague, as it is used for all
kinds of things (currency codes, business center codes, etc.)
Maybe, as Andrew Jacobs suggested, all of that type of information
(alternate identifiers/codes/labels) belongs strictly in the party trade
information block, to indicate that it’s not used by the document creator for
identification.
-
Brian
From: mtf@xxxxxxxx
[mailto:mtf@xxxxxxxx] On Behalf Of matthew.d.rawlings@xxxxxxxxxxxx
Sent: Friday, March 07, 2008 8:23 AM
To: mtf@xxxxxxxx
Subject: Re: Business object identification proposed requirements.
It would be far
simpler not to use the term "Identifier" for things that are not
Identifiers (non-unique, non-immutable). That way we'd call things what they
are and not get into discussions about 'special' identfiers. For example
everything that is non-unique or non-immutable we could just call a
"code".
Matthew
Rawlings
+44 7917 596 827
|
"Brian
Lynn" <brian.lynn@xxxxxxxxxxxxxxxxxxx>
Sent by:
mtf@xxxxxxxx
07/03/2008
12:37
|
Please respond to
mtf@xxxxxxxx
|
|
|
To
|
<mtf@xxxxxxxx>
|
|
cc
|
|
|
Subject
|
Business
object identification proposed requirements.
|
|
I had an action from last week’s MTF to update the proposed requirements for
business object identification to clarify some points raised during the
meeting.
Below is an extract of those updated proposed requirements. Given the
other items on the agenda for today’s meeting, we will probably discuss this
next week.
Requirements
To simplify the processing requirements for FpML recipients, I propose the
following requirements for business object identification:
- Each document creator shall be required to
designate an identifier that it uses for identifying business objects.
This identifier must be immutable (must not change during the life
of the object) and unique (must not be assigned to more than one object).
- In addition, document creators shall be able to
record other identifying tokens that they believe other sources use to
identify that business object.
- The other identifying tokens may be updated as
new information becomes available. The original identifier may not
be updated, except through an explicit interaction with the recipient
(e.g. cancel and rebook).
- Document recipients shall be able easily to
determine which identifier was designated by the sender as unique and
immutable, and shall be able to use the identifier designated by the
document sender to retrieve their own view of the current state of that
object.
- Each document creator shall be able to assign and
update a single version number for a given business object; this version
number reports the version of the object from the sender’s perspective.
- Document recipients shall be able to use this
version number to determine whether a message contains a newer
version of the business object than they have previously received from the
sender.
- In addition, document creators shall have the
ability (but not the obligation) to report on the latest known versions of
the business object from other sources.
- Similarly, document creators shall be able to
report the timestamp of their last update to the business object.
(This will normally be similar to the message timestamp, but may be
different, for example in the case of a position reporting message
generated without an update to the object).
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.