Multiple identifiers for multiple parties in flat-file standards

 Party Names and Party Identifiers

Some records in the DSR and CDM standards allow to report multiple parties, this happens for instance in MW01 records with the need to send multiple writers, this fields would generally be broken down into two cells:

• One cell for the name of the parties (e.g. ComposerAuthorName) and 

• One Cell for the identifiers (e.g. ComposerAuthorPartyId).

These two Cells are linked, i.e. the order in which the names and the identifiers are provided, needs to be the same so that the recipient of the message can know which names belongs with which identifier. The first name belongs with the first identifier, the second name belongs with the second identifier and so on. Changing the order of one of the fields without changing the order in the linked field would lead the wrong attribution of names and identifiers. Consequently, if there are only identifiers for a subset of the parties, then an empty space in the right place would need to be left to indicate that there is no identifier for that particular party.

For instance, if a Message Sender had the follow information:

the fields ComposerAuthorName and ComposerAuthorPartyId would be provided by using the “secondary delimiter”, the pipe character (|). The identifiers themselves also need to be namespaced using the double colon syntax:

Note that the two adjacent pipe characters indicate that the second name, John Smith, is not accompanied by an identifier.

Multiple Party Identifiers

If the Message Sender wants to report multiple identifiers for any given party, the individual identifiers can be communicated using the escaping mechanism described below.

The examples use the following data:

Process to write multiple identifiers

Step 1 – The content of each identifier needs to be escaped, this is done by adding a single backslash (\) character in front of any backslash, pipe or tab character. This is only necessary if any of the identifiers contain a backslash, pipe or tab character.

Step 2 – Creation of a single identifier string for each party’s identifiers by separating them with pipes. For Jane Smith this would be

IPI::31823461941|ISNI::9876876576546543

Step 3 – The content of this string needs to be escaped by adding a single backslash character in front of any backslash, pipe or tab character. For Jane Smith this would become

IPI::31823461941\|ISNI::9876876576546543

Step 4 – All identifier strings can now be combined, separated by an un-escaped pipe character. For Jane Smith and Peter Miller we would have:

IPI::31823461941\|ISNI::9876876576546543|IPI::73519527851\|ISNI::1234234534564567

Step 5 – The content of this string needs to be escaped by adding a single backslash character in front of any backslash or tab character.

IPI::31823461941\\|ISNI::9876876576546543|IPI::73519527851\\|ISNI::1234234534564567

Step 6 – This string can now be combined with the names and placed into the message: 

Extracting Information

The process of extracting the identifiers is the inverse of the above: (i) “un-escape” the record containing the identifiers and extract the name/identifier cell pair, (ii) split the ID cell into the strings for each party at the pipe character, (iii) take each of these sub strings and “un-escape” them by removing all backslashes, and (iv) split the sub-strings at the pipe character into the individual identifiers:

If there are escaped characters in the identifiers the process of un-escaping is more complex as one additional step of un-escaping these strings is required. Whether this is necessary can be determined by checking if any of the strings resulting from step (iv) contains a backslash.