Proposal: Add upper bound to element IDs

[patricklucas]

Currently, element IDs use the id_t type in the Orchestra XSD. id_t is defined as:

	<xs:simpleType name="id_t">
		<xs:restriction base="xs:positiveInteger"/>
	</xs:simpleType>

This allows for any positive integer to be used as an element ID, with no upper bound, which is awkward to handle in software.

Implementations either have to use a "big integer" type, if one is available, or fall back to using strings if not. This results in frequent conversions back and forth when a normal numeric value is required.

I propose adding an upper bound of 2^32 - 1 (2147483647) to id_t, so that implementations can represent these IDs in a signed 4-byte integer.

• Are there compelling use-cases for very large numeric IDs (greater than 2 billion)?
• I also considered setting the upper bound to 2^64 - 1 (to fit in a signed 8-byte integer), but this is already larger than JavaScript, for one, can represent natively
• If we do think that a significantly larger "ID space" is required for some applications, a better path forward would be to use string identifiers rather than numbers, but this is more of a breaking change
• Reducing the upper bound from infinity to not infinity is of course a breaking change, but I think the impact will still be low

New definition of id_t:

	<xs:simpleType name="id_t">
        <xs:restriction base="xs:positiveInteger">
            <xs:maxInclusive value="2147483647"/>
        </xs:restriction>
    </xs:simpleType>

[kleihan]

The IDs are currently xs:positiveInteger, i.e. must not be negative. Why then a signed 4-byte integer? The range would go from 1 to 4,294,967,295 if we define an unsigned integer to be used.

[patricklucas]

I'm just thinking of Java, where all integers are signed. Java must use Long to represent values greater than 2147483647.

We could go with unsigned, and Java implementations would use Long, but at that point we could go higher. Java Longs have a max value of 2^63 - 1. JavaScript can represent up to 2^53 - 1.

It just starts to feel arbitrary at some point—what range of values is actually useful vs. just masking other problems?

[kleihan]

Agree that we do not need IDs higher than 2^32-1 as this indicates some form of "intelligent" IDs that is actually a concatenation of multiple independent numbers. Orchestra IDs are meant to be simple numbers that usually start with 1. FIX Latest does have some conventions in terms of ID ranges for fields (used for tag numbers) but that is all well within the suggested boundary. Ease of implementation is of value and Java is a very important use case. I am fine to set the boundary as proposed.