Understanding TWIST Notation
TwistMessage
The root of a TWIST message is the element TwistMessage. TwistMessage is composed of four elements: messageHeader, conversationIdentification, a conversation element, and party. The message header is always present and is used to record who sent the message and to whom. Refer to the messageHeader diagram to review its contents. Next is identification of the message. A conversation is a sequence of messages and it is frequently necessary to refer to earlier messages of the same conversation. Third is a conversation. These come in two flavors: trade, tradeStatement, settlement, account and setup. The model organizes these conversations in separate elements. The table of contents will summarize the structure of these conversations. Last in the TwistMessage is a collection of party elements. Parties are used throughout the specification and it is desirable to simply reference a detailed description of the party rather than repeat this information everywhere. Party and other foundation elements are described at the end of this document.
messageHeader
The header identifies the message, the version of TWIST being used and who sent it. The header is not used for line protocol. The messageHeader is part of the message if it were delivered on a floppy disk, written to a disk file, telnetted to another location, or copied to a CD before being delivered.
conversationIdentification
This element is used to identify the conversation to which this message belongs. The initial message in a conversation creates a new conversationId.
A conversation is identified with a conversationId. Any message in a conversation must reference its conversation using this id. The user who created this message is next, followed by any comments included in this step of the conversation.
conversation groups
Conversations are divided into groups as illustrated in the following picture. Each message must be formed from exactly one conversation element in one of these groupings.
As the names suggest each grouping has something in common:
- TradeConversations all focus on a single trade.
- TradeStatements are conversations that work with collections of trades.
- Settlements are managed using the settlementConversation group
- AccountConversations are used in several workflows where payments to accounts are managed.
- Setup is used to configure relationships. Credit limit setups is an example.
A note on the word “conversation.” In all the workflows we are modelling dialogs between users, user and machines or machines to machines. These dialogs are almost always a series of messages passed back and forth between two parties – hence a conversation. These are clearly formal conversations since the standard specifies what you can say at each step.
Parties
The last elements in a message are party definitions. These are required for any party referenced within the body of the message. Typical examples are receivingParty, payingParty.