[repository schema] Version attribute should not be so restrictive

[donmendelson]

The format of the repository version attribute should be more freeform. The SBE schema has a simple integer for version, but I found that the Orchestra schema would not allow that in a translation.

[donmendelson]

An alternative to consider is to move the name and version attributes to the metadata section as Dublin Core Terms, e.g. title, identifier.

[donmendelson]

Without imposing DCT or PROV models, I propose simply changing Version_t XML type to the following.

<xs:simpleType name="Version_t">
	<xs:restriction base="xs:token">
		<xs:annotation>
			<xs:documentation>Uniquely identifies a revision. Many formats are impossible, including but not limited to protocol version label, semantic versioning, date, or simple integer.
				The format may be restricted by an external style.
			</xs:documentation>
		</xs:annotation>
	</xs:restriction>
</xs:simpleType>

[patricklucas]

Beyond being restrictive, the version attribute is documented as being specifically a FIX version, which seems to be anathema to Orchestra's claim of being applicable to non-FIX use-cases.

I'm currently looking into Orchestra to help with the specification of financial services data which is not necessarily FIX or FIX-encoded, but where we would like to have a common approach and unified semantic data model across different use-cases, some FIX and some not.

Coming from that perspective, I've found a few stumbling blocks like this where Orchestra does seem tied to FIX rather than being more general purpose—is that something the FIX community intends to try to address?

[donmendelson]

@patricklucas this change was indeed to support non-FIX protocols or firms that wish to follow their own version system. As I mentioned, the v1.0 schema did not even support the integer version number in SBE which is a FIX standard!

Please raise issues for the stumbling blocks you alluded to.

[kleihan]

@patricklucas first of all thank you for getting involved with Orchestra and raising issues. I suspect that your comment about Orchestra being FIX only in some places relates to specification snippets like the following:

The root element an Orchestra respository XML file is <repository>. An Orchestra repository file contains all the message structures and workflow elements pertaining to a single protocol version. If an organization supports multiple versions of FIX, it should supply an Orchestra file for each.

You may have seen that we are currently working on the first Release Candidate for Version 1.1. I will take your comment to enter an issue for fix-orchestra-spec to make the spec more agnostic. Obviously, it is being developed by FIX so that the examples are using the FIX Protocol. We want people to standardize and do not want encourage proprietary protocols. At the same time we are very aware of the fact that they exist and will continue to exist. We would be happy to see Orchestra also being used for such non-FIX protocols and it would be great if you could share your experience.

Version 1.1 is not final yet, there will be more Release Candidates so that we can still add capabilities.

[kleihan]

Implemented in RC1