[repository schema] Some protocols's message names are not supported by Name_t restrictions.

[francescoloconte]

Some exchange protocols, like JPX Arrowhead, use long names for their messages. These names can contain several words and spaces, like this one: "Cancel Order Message (Specifying Order Acceptance Number)". Their type instead is simple: "3121"

However, Orchestra’s messageType.name is of type Name_t, which is restrictive, since it does not support spaces, and other characters that may be required by these message names.

I think that currently, for a Message, both msgType and name are used as unique identifiers. This is the reason for the restrictions on Name_t.

Would it make sense to have msgType as the only identifier for a message, and relax the name attribute to allow what would be a descriptive name for a message?

[francescoloconte]

As a side note, the rendering attribute is "kind of close" to what we need, however, it was added to support GUI, and it is not currently on the messageType element. I think the more important decision is whether message elements should support two types of ID: name and msgType.

[francescoloconte]

@kleihan, what are your thoughts on discontinuing the use of the name attribute as a unique identifier for messages?

The rationale for this is that message names can be complex and include spaces or special characters, as seen in the JPX case. Therefore, they are not ideal for unique identification. I propose using the msgType attribute as the unique identifier instead. This change would relax the format restrictions on the name attribute, allowing users to assign more descriptive names to messages, such as "Cancel Order Message (Specifying Order Acceptance Number)" in an exchange protocol.

If this proposal was valid, I would follow up with a PR for this change.

[patricklucas]

I think there are two discussions to have that are related to this:

• unique and semantic identifiers for resources in contrast to longer descriptive names
• the relationship between resource IDs/names and specific encodings

Currently, most resource types have two identifiers, a positive integer ID and Name_t name, both of which must be unique (ignoring scenario for the moment). In general, I find it useful to have both of these sorts of IDs, but I think we could codify their usage better. I also think there is value in having a "simple name" that can be used in programmatic contexts—think URLs/URNs, variable names and so forth.

I think my suggestion to deal with the specific problem brought up in this issue would be to add support for an optional "display name" on resources. This could be added in a few different ways: simply adding an additional attribute displayName, adding a documentation element with "purpose" DISPLAY_NAME, and others.

As far as whether resources should have both a numeric ID and (simple) string name, there can be value there if we codify a bit tighter the uniqueness requirements for them.

One potential source of inspiration is Kubernetes, in which all resources have two identifiers that can be used to uniquely identify them:

• A uid, unique ID, that must be unique in "space and time"—that is, even if the resource is deleted and recreated with the same name, the new resource must have a new uid
• A name, that must be unique in space—you can only have one resource with a specific name at a given time, but if you delete it, you could create it again later with the same name (but a different uid)

For Orchestra, we could consider using id as the uid: perhaps a field is deprecated and removed, but re-added later. In that case, the field would be allowed to have the same name, but must receive a new id. name would work the same way as it does today; you can only have one resource (for a particular resource type) with a specific name in any given version. Finally, the "display name" is simply a descriptive string, and does not have any explicit uniqueness requirement.

[kleihan]

@francescoloconte the definition of Name_t has already been "deFIXified" with Orchestra v1.1 RC1. I suggest to close the issue.

	<xs:simpleType name="Name_t">
		<xs:annotation>
			<xs:documentation>Names are from 1-64 characters. The XML processor will remove line feeds, carriage returns, tabs, leading and trailing spaces, and multiple spaces. Single internal spaces are allowed by the schema but may be restricted by an external style.</xs:documentation>
		</xs:annotation>
		<xs:restriction base="xs:token">
			<xs:minLength value="1"/>
			<xs:maxLength value="64"/>
		</xs:restriction>
	</xs:simpleType>

Furthermore, the attribute purpose="DISPLAY"can be used for the documentation element of a message to add a more descriptive name as you suggest above. However, DISPLAY is not really defined in RC1. This omission should be covered in v1.1.