Playlist User Guide
Playlist is a tool to visualize an Orchestra XML file and reduce it to a subset exported into a new Orchestra XML file. Playlist is not a FIX validation tool, i.e. it relies on the correctness of the input file and the FIX knowledge of the user. For example, it is the responsibility of the user to ensure the proper selection of fields required by FIX, i.e. the tool will not complain if the user only selects stop order types but fails to select the StopPx(99) field. The only exception to this rule is that StandardHeader and StandardTrailer do not have to be selected and will automatically be added to each of the selected messages when creating the new Orchestra XML file. This includes the pre-selection of required fields in the StandardHeader component (BeginString(8), BodyLength(9), MsgType(35),…) for the tag=value encoding.
Login and Logout
Access to Playlist requires you to register and login to the FIX Trading Community website, and your confirmed affiliation with a FIX member firm. Once you are confirmed to be affiliated with a FIX member firm you can request access to Playlist, please contact the FIX Program Office (email@example.com) for access. There is no explicit function to logout of Playlist, i.e. you can just close your browser tab.
Input and Output
Playlist requires an Orchestra XML file as input. It serves as a reference file for both the display and for the new Orchestra XML file created as output. The input file has to conform to the schema of the Orchestra Technical Standard Version 1.0. It is possible to change the input by reading a new Orchestra XML file. These files are not uploaded to the FIX infrastructure and remain local in the memory of your browser. You can press “Clear Input File” or refresh your browser window to remove the current input file.
Playlist provides direct access to official FIX Orchestra XML files in the public GitHub project FIX Orchestrations. You may use local files (click on “Choose File”) but do not have to download any of the official files for FIX 4.2, FIX 4.4 or FIX Latest from the FIX website. Simply click on “FIX Standard” to get a list of XML files available in the FIX Standard folder in GitHub:
The file name for the new Orchestra XML file defaults to “myorchestra.xml” but you can easily change it by clicking into the field. The button “Create Orchestra file” is accessible as soon as you have read in an input file and made a selection. Playlist does not require the selection to include a FIX message, i.e. you can also create a subset of the input file that only includes a single group or component. Fields depend on being automatically enabled in the context of a message, group or component and cannot be selected independently. The download of the Orchestra XML file is preceded with a screen showing the number of elements included from each type (messages, groups, components, standard fields, code sets, codes, datatypes).
Repository Visualization and Handling
The repository is shown in six different sections described below. Entire sections and their elements (message, repeating group, component, field, code set, code value) can be expanded (click on “+”) or collapsed (click on “-“), with each element having its own check box. All check boxes have two settings: selected and not selected. A third setting, partially selected, is possible for elements containing other elements. The user can only select or deselect a check box, partial selections are the result of Playlist indicating that some but not all of the nested elements have been selected.
Some of the check boxes are read-only as they are automatically set by Playlist. For example, selecting the check box of a message enables all of its groups, components and fields. Selecting a single field within a message will result in Playlist showing the message as partially selected. Selecting a partially selected check box changes it to being deselected, and changing it to being fully selected requires selecting the check box again for a second time.
Alphabetical list of messages can be expanded to show its groups, components, and fields. These are also sorted alphabetically to ease searching in large messages. The fields are shown with their name, tag number and datatype or code set with its base type (if applicable). The groups and components can be expanded to the first nesting level. StandardHeader and StandardTrailer of messages are not shown but will automatically be added to each of the selected messages when creating the new Orchestra XML file.
Alphabetical list of all repeating groups (regardless of nesting level) can be expanded to show its nested groups, components, and fields. These are also sorted alphabetically to ease searching in large groups. The fields are shown with their name, tag number and datatype or code set. The nested groups and components cannot be expanded in place but are part of the single list of repeating groups or components (see next section). The fields with NumInGroup datatype for fields of repeating groups are shown as read-only and will automatically be selected when at least one element of the repeating group is selected.
Alphabetical list of all components (regardless of nesting level) can be expanded to show its nested groups, components, and fields. These are also sorted alphabetically to ease searching in large components. The fields are shown with their name, tag number and datatype or code set. The nested groups and components cannot be expanded in place but are part of the single list of repeating groups (see previous section) or components.
Fields are a read-only section, i.e. they are automatically shown as selected when enabling them in a message, group or component and vice-versa when disabled again. Fields are grouped by tag numbers into groups of 1,000 tags at a time and sorted by tag number. The tag ranges can be expanded to show individual fields. These are shown with their name, tag number, datatype, union datatype (if applicable) and base datatype (only for code sets).
Code sets (a.k.a. enumerated values) are independent elements in the Orchestra Technical Standard. They have a name that is derived from the main FIX field that uses its values and are listed alphabetically with their name and datatype. The individual codes are shown with their value and symbolic name (shown in FIXimate inside square brackets).
The code sets themselves are read-only and automatically shown as (partially) selected when enabling a field in a message, group or component that uses them. The code set will be deselected when there is no more selected field that uses it. The individual codes can be selected or deselected as long as at least one code has been selected. Once (partially) selected, deselecting a code set requires the user to deselect all fields using that code set from messages, groups and components.
Datatypes are a read-only section as they are automatically shown as selected when enabling a field with this datatype in a message, group or component. They are automatically disabled if no field with this datatype is selected.
Selector File to Extend an Orchestra XML file
Once the input file has been loaded into memory (the button “Use Selector File” will otherwise be disabled), it is possible to identify a second file called “selector file” to preselect elements as if one had manually selected them one by one.
The use case for a selector file is an Orchestra XML file that was created but needs to be slightly extended, e.g. by adding a few more fields to a message or values to a field. These elements may have simply been forgotten or are part of an interface update. The input file needs to contain these additional elements. After loading the selector file, elements from that file will be preselected and elements that are only in the (larger) input file may be additionally selected manually. The creation of a new Orchestra XML file ends the process.
The reverse process to slightly reduce an Orchestra XML file can also benefit from the use of a selector file. The key is to use the same file as input and selector file. This will cause everything to be preselected. Now you can remove the few elements and create a new Orchestra XML file.
This section describes known limitations of the current version and provides workarounds where available.
- It is not possible to deselect the last code of a code set even if the code set is currently not used by any field. This happens when you go into the code set section and select a code of an unused code. The workaround is to select a field using that code set in any of the messages, groups or components and immediately deselecting it. As it is the only usage, the deselection of the field also causes the entire code set to be deselected.
- When uploading an input file containing the components StandardHeader and StandardTrailer, its required fields will automatically be selected for convenience. One of these fields is MsgType(35), which causes the entire code set MsgTypeCodeSet and all of its codes to be selected as well. This may require to deselect a large number of codes, especially if the input file is the official one for FIX Latest which contain more than 160 message types. The workaround is to go into the components section where the StandardHeader is defined, deselect MsgType(35) to remove MsgTypeCodeSet in its entirety, then go to the code sets section and select the desired codes of MsgTypeCodeSet. Once the codes are selected, go back to the StandardHeader and select MsgType(35) again. It will not change the selected subset in MsgTypeCodeSet.
- Playlist does not support Orchestra scenarios. You can create the superset (scenario=”base”) of your scenarios for a message, group, component or code set with Playlist and convert the resulting Orchestra XML file to Tablature markdown. You can then duplicate the superset for each scenario, add the scenario name and remove elements that are not part of the given scenario. The modified markdown file can then be converted back to an Orchestra XML file. It is not recommended to manually edit the Orchestra XML file.