# Consistent message naming **URL:** \ **Category:** General Q&A\ **Tags:** xid\_169877, imported, repository\ **Created:** [September 8, 2009, 12:08pm UTC](https://forum.fixtrading.org/t/consistent-message-naming/5954 "2009-09-08T12:08:36Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![johncameron](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/johncameron/32/56_2.png) [@johncameron](https://forum.fixtrading.org/u/johncameron)\ **Post date:** [September 8, 2009, 12:08pm UTC](https://forum.fixtrading.org/t/consistent-message-naming/5954/1 "2009-09-08T12:08:36Z")
Imported from previous forum ---
**Author:** ![johncameron](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/johncameron/32/56_2.png) [@johncameron](https://forum.fixtrading.org/u/johncameron)\ **Post date:** [September 8, 2009, 12:08pm UTC](https://forum.fixtrading.org/t/consistent-message-naming/5954/2 "2009-09-08T12:08:36Z")
The FIX specification, Volume 6, in the enumerated values of the MsgType field names two values - and hence two messages - in what is arguably an inconsistent manner. MsgType AU - Confirmation\_Ack MsgType n - XML\_non\_FIX These are the only two names which use the underscore character. The standard everywhere else is to use "camel case" naming convention. The FIX repository follows the specification. I suggest that it would be more consistent to name these messages as: ConfirmationAck and XMLNonFIX Does anyone disagree with this? ---
**Author:** ![hanno.klein](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/hanno.klein/32/38_2.png) [@hanno.klein](https://forum.fixtrading.org/u/hanno.klein)\ **Post date:** [September 8, 2009, 12:33pm UTC](https://forum.fixtrading.org/t/consistent-message-naming/5954/3 "2009-09-08T12:33:56Z")
No objection but due process involving a gap analysis document is required for such a change. A quick look at Confirmation\_Ack reveals multiple errors which can then be corrected in the same gap analysis. I spotted these: - Comment of 58 Text is a cut&paste error from AllocationReportAck - 940 AffirmStatus used instead of 665 ConfirmStatus - 774 ConfirmRejReason refers to ConfirmStatus “1 (rejected)” instead of value “5 Request Rejected” - Comment of 60 TransactTime is a cut&paste error from AllocationInstructionAck > The FIX specification, Volume 6, in the enumerated values of the MsgType > field names two values - and hence two messages - in what is arguably an > inconsistent manner. > > MsgType AU - Confirmation\_Ack MsgType n - XML\_non\_FIX > > These are the only two names which use the underscore character. The > standard everywhere else is to use “camel case” naming convention. > > The FIX repository follows the specification. > > I suggest that it would be more consistent to name these messages as: > > ConfirmationAck and XMLNonFIX > > Does anyone disagree with this? ---
**Author:** ![johncameron](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/johncameron/32/56_2.png) [@johncameron](https://forum.fixtrading.org/u/johncameron)\ **Post date:** [September 9, 2009, 12:06am UTC](https://forum.fixtrading.org/t/consistent-message-naming/5954/4 "2009-09-09T00:06:35Z")
I think that AffirmStatus is the correct and intended field (the ConfirmationAck messages is also known as the Affirmation message). The error is that 774 ConfirmRejReason should refer to AffirmStatus “2 ConfirmRejected” > No objection but due process involving a gap analysis document is > required for such a change. A quick look at Confirmation\_Ack reveals > multiple errors which can then be corrected in the same gap analysis. I > spotted these: > > - Comment of 58 Text is a cut&paste error from AllocationReportAck > - 940 AffirmStatus used instead of 665 ConfirmStatus > - 774 ConfirmRejReason refers to ConfirmStatus “1 (rejected)” instead of > value “5 Request Rejected” > - Comment of 60 TransactTime is a cut&paste error from > AllocationInstructionAck > > > The FIX specification, Volume 6, in the enumerated values of the > > MsgType field names two values - and hence two messages - in what is > > arguably an inconsistent manner. > > > > MsgType AU - Confirmation\_Ack MsgType n - XML\_non\_FIX > > > > These are the only two names which use the underscore character. The > > standard everywhere else is to use “camel case” naming convention. > > > > The FIX repository follows the specification. > > > > I suggest that it would be more consistent to name these messages as: > > > > ConfirmationAck and XMLNonFIX > > > > Does anyone disagree with this? ---
**Author:** ![johncameron](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/johncameron/32/56_2.png) [@johncameron](https://forum.fixtrading.org/u/johncameron)\ **Post date:** [September 9, 2009, 12:22am UTC](https://forum.fixtrading.org/t/consistent-message-naming/5954/5 "2009-09-09T00:22:15Z")
Will you add these errors to JIRA? I know that it is not the official way of reporting errors but I have also added these errors to FIXwiki ([http://cameronedge.com/fixwiki/Confirmation\_Ack/FIX.4.4%2B#Notes](http://cameronedge.com/fixwiki/Confirmation_Ack/FIX.4.4%2B#Notes)). I think that using FIXwiki for reporting errors is something that should be considered. I think it has several advantages as a first line of error reporting (with JIRA as the second line, once errors have been validated). The main advantages are: - it is a formal process open to the whole FIX community. Many eyes on the spec are better than just a few. - Reported errors are visible to everyone else on the FIXwiki, in the relevant area. So everyone one knows that an error is present and that it has already been reported. Note that a complete list of all reported errors is always available on FIXwiki by clicking on the FIX Spec Errors link in the navigation area on the left of each FIXwiki page. > I think that AffirmStatus is the correct and intended field (the > ConfirmationAck messages is also known as the Affirmation message). > > The error is that 774 ConfirmRejReason should refer to AffirmStatus “2 > ConfirmRejected” > > > No objection but due process involving a gap analysis document is > > required for such a change. A quick look at Confirmation\_Ack reveals > > multiple errors which can then be corrected in the same gap analysis. > > I spotted these: > > > > - Comment of 58 Text is a cut&paste error from AllocationReportAck > > - 940 AffirmStatus used instead of 665 ConfirmStatus > > - 774 ConfirmRejReason refers to ConfirmStatus “1 (rejected)” instead > > of value “5 Request Rejected” > > - Comment of 60 TransactTime is a cut&paste error from > > AllocationInstructionAck > > > > > The FIX specification, Volume 6, in the enumerated values of the > > > MsgType field names two values - and hence two messages - in what is > > > arguably an inconsistent manner. > > > > > > MsgType AU - Confirmation\_Ack MsgType n - XML\_non\_FIX > > > > > > These are the only two names which use the underscore character. The > > > standard everywhere else is to use “camel case” naming convention. > > > > > > The FIX repository follows the specification. > > > > > > I suggest that it would be more consistent to name these > > > messages as: > > > > > > ConfirmationAck and XMLNonFIX > > > > > > Does anyone disagree with this? ---
**Author:** ![hanno.klein](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/hanno.klein/32/38_2.png) [@hanno.klein](https://forum.fixtrading.org/u/hanno.klein)\ **Post date:** [September 9, 2009, 8:33am UTC](https://forum.fixtrading.org/t/consistent-message-naming/5954/6 "2009-09-09T08:33:35Z")
I support the idea of using FIXwiki for initial error reporting as the discussion forums are not sufficiently focussed. In order to work properly, I believe a little more formality is needed. First of all, I would use the term “issue” instead of “error” and have the classification (e.g. error, improvement) be the result of the validation. For example, the “error” of Party Role 11/OrderOriginationTrader is more of a clarification. Improvements should normally be brought forward by means of a gap analysis which requires some effort by the submitter. I would not want people to mis-use FIXwiki by entering everything they want to add or change as an issue. We currently have some improvement issues in Jira which are “waiting” for someone to take ownership, commit to the work of writing a gap analysis document and presenting it to the relevant committees. Only small improvements like the example above (glossary update) can be easily added to the spec when compiling a new release. Secondly, the classification (including rejections, i.e. non-issues and issues requiring a gap analysis) and transition to Jira needs to be shown in the Wiki and the related editing would need to be restricted to those that also have Jira access and support the actual fixing of issues. Last not least, any errors that have been fixed with a new release of the FIX spec need to be removed or moved to an archive which contains the version under which it was once reported. The initial reporting facility needs to be limited to the current version. FPL can then decide to issue an errata release which would also require all included issues to be moved to the archive. I would hope that such a facility would increase the quality of the spec without flooding the limited resources of FPL with extra work. It is certainly worth a try and I would be willing to contribute by analyzing and classifying reported issues and transferring them to Jira. > Will you add these errors to JIRA? > > I know that it is not the official way of reporting errors but I have > also added these errors to FIXwiki > ([http://cameronedge.com/fixwiki/Confirmation\_Ack/FIX.4.4%2B#Notes](http://cameronedge.com/fixwiki/Confirmation_Ack/FIX.4.4%2B#Notes)). > > I think that using FIXwiki for reporting errors is something that should > be considered. I think it has several advantages as a first line of > error reporting (with JIRA as the second line, once errors have been > validated). > > The main advantages are: > > - it is a formal process open to the whole FIX community. Many eyes on > the spec are better than just a few. > > - Reported errors are visible to everyone else on the FIXwiki, in the > relevant area. So everyone one knows that an error is present and that > it has already been reported. > > Note that a complete list of all reported errors is always available on > FIXwiki by clicking on the FIX Spec Errors link in the navigation area > on the left of each FIXwiki page. ---
**Author:** ![johncameron](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/johncameron/32/56_2.png) [@johncameron](https://forum.fixtrading.org/u/johncameron)\ **Post date:** [September 10, 2009, 5:01am UTC](https://forum.fixtrading.org/t/consistent-message-naming/5954/7 "2009-09-10T05:01:51Z")
We are probably getting a bit off topic. Which forum would suit this discussion best? Anyway, for now, lets continue here… I deliberately chose the term “Error” because I thought we would start by only reporting clear mistakes rather than “wish lists”. There are quite a few clear mistakes in the FIX spec - including silly things like spelling errors and typos. In my opinion, such errors might be trivial but they make the specification look sloppy and unprofessional and I think they should be fixed as a matter of urgency. These simple “errors” should require minimal validation and should be able to be “fast tracked” into the specification without needing to pass through JIRA or a formal committee approval. Or, at most, a whole bunch of them could be approved en-masse in a single committee meeting - maybe just by committee members viewing and approving the errors directly in FIXwiki - without needing to copy them into any other document. That is what I think we should start with. However, going forward, I agree with all your points about a more formal process for more general “issues”. > I support the idea of using FIXwiki for initial error reporting as the > discussion forums are not sufficiently focussed. In order to work > properly, I believe a little more formality is needed. First of all, I > would use the term “issue” instead of “error” and have the > classification (e.g. error, improvement) be the result of the > validation. For example, the “error” of Party Role > 11/OrderOriginationTrader is more of a clarification. Improvements > should normally be brought forward by means of a gap analysis which > requires some effort by the submitter. I would not want people to mis- > use FIXwiki by entering everything they want to add or change as an > issue. We currently have some improvement issues in Jira which are > “waiting” for someone to take ownership, commit to the work of writing a > gap analysis document and presenting it to the relevant committees. Only > small improvements like the example above (glossary update) can be > easily added to the spec when compiling a new release. > > Secondly, the classification (including rejections, i.e. non-issues > and issues requiring a gap analysis) and transition to Jira needs to > be shown in the Wiki and the related editing would need to be > restricted to those that also have Jira access and support the actual > fixing of issues. > > Last not least, any errors that have been fixed with a new release of > the FIX spec need to be removed or moved to an archive which contains > the version under which it was once reported. The initial reporting > facility needs to be limited to the current version. FPL can then decide > to issue an errata release which would also require all included issues > to be moved to the archive. > > I would hope that such a facility would increase the quality of the spec > without flooding the limited resources of FPL with extra work. It is > certainly worth a try and I would be willing to contribute by analyzing > and classifying reported issues and transferring them to Jira. > > > Will you add these errors to JIRA? > > > > I know that it is not the official way of reporting errors but I have > > also added these errors to FIXwiki > > ([http://cameronedge.com/fixwiki/Confirmation\_Ack/FIX.4.4%2B#Notes](http://cameronedge.com/fixwiki/Confirmation_Ack/FIX.4.4%2B#Notes)). > > > > I think that using FIXwiki for reporting errors is something that > > should be considered. I think it has several advantages as a first > > line of error reporting (with JIRA as the second line, once errors > > have been validated). > > > > The main advantages are: > > > > - it is a formal process open to the whole FIX community. Many eyes on > > the spec are better than just a few. > > > > - Reported errors are visible to everyone else on the FIXwiki, in the > > relevant area. So everyone one knows that an error is present and > > that it has already been reported. > > > > Note that a complete list of all reported errors is always available > > on FIXwiki by clicking on the FIX Spec Errors link in the navigation > > area on the left of each FIXwiki page. ---
**Author:** ![hanno.klein](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/hanno.klein/32/38_2.png) [@hanno.klein](https://forum.fixtrading.org/u/hanno.klein)\ **Post date:** [September 9, 2009, 8:10am UTC](https://forum.fixtrading.org/t/consistent-message-naming/5954/8 "2009-09-09T08:10:47Z")
I stumbled over the fact that the Confirmation message uses COnfirmStatus whereas Confirmation\_Ack uses AffirmStatus. I can’t say that I am familiar with the related business processes but it does appear inconsistent at first sight. Both fields do not appear in any other message. So I guess the idea is to affirm the confirmation by means of Confirmation\_Ack, sorry for the mistake. ExecutionAcknowledgment chose a different path, i.e. ExecAckStatus, to acknowledge an execution report. If “Affirmation” is a well known business term then a change of field name from AffirmStatus to ConfirmAckStatus would not be desirable. > I think that AffirmStatus is the correct and intended field (the > ConfirmationAck messages is also known as the Affirmation message). > > The error is that 774 ConfirmRejReason should refer to AffirmStatus “2 > ConfirmRejected” > > > No objection but due process involving a gap analysis document is > > required for such a change. A quick look at Confirmation\_Ack reveals > > multiple errors which can then be corrected in the same gap analysis. > > I spotted these: > > > > - Comment of 58 Text is a cut&paste error from AllocationReportAck > > - 940 AffirmStatus used instead of 665 ConfirmStatus > > - 774 ConfirmRejReason refers to ConfirmStatus “1 (rejected)” instead > > of value “5 Request Rejected” > > - Comment of 60 TransactTime is a cut&paste error from > > AllocationInstructionAck > > > > > The FIX specification, Volume 6, in the enumerated values of the > > > MsgType field names two values - and hence two messages - in what is > > > arguably an inconsistent manner. > > > > > > MsgType AU - Confirmation\_Ack MsgType n - XML\_non\_FIX > > > > > > These are the only two names which use the underscore character. The > > > standard everywhere else is to use “camel case” naming convention. > > > > > > The FIX repository follows the specification. > > > > > > I suggest that it would be more consistent to name these > > > messages as: > > > > > > ConfirmationAck and XMLNonFIX > > > > > > Does anyone disagree with this?