Imported from previous forum
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?
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?
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
AllocationInstructionAckThe 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?
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).
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
AllocationInstructionAckThe 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?
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).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.
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).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 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
AllocationInstructionAckThe 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?