Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Default
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.0.2
-
Component/s: Metadata/Specs
-
Labels:None
Description
1) A very minor inconsistency is that FIX42 and 43 end elements like "/> (without a space) and 44 ends like " /> (with a space).
2) MarketDepth is a funny Field. It is like an enum, in that values for 0 and 1 have names. It is different from an enum in that values >1 are legal,
so not all values are enumerated. This is a problem, as we would like the code generation to generate the magic constants, but we don't want validation to insist on only having 0 or 1.
At the moment the 3 relevant FIX xml files are inconsistent. FIX42.xml has the enum in, FIX43.xml has it in, but commented out with an explanatory comment,
and FIX44.xml doesn't have the enumerated fields mentioned at all. Because FIX44.xml is checked first, this leads to the magic constants not being generated, and validation working as hoped.
Possible solutions:
1) I'll attach a search and replace version of FIX44 to make the formatting consistent for both. A good reason for this is it makes doing a diff between the files much easier.
2) I can't find anywhere in the code that breaks if the enums for MarketDepth are there, but I might not be looking in the right place. After all, you would hope enums were validated. Can the enums just be put back in (for 43 and 44)? I'll attached the files with the enums back in, and a comment mentioning the N>1 case if you want to add them back.
Attachments
Activity
The FIX 42,43, and 44 files with the enumerated values for MarketDepth added back in, and a comment added to mention the N>1 case
How about having an empty value element:
<field ...>
<value enum="..." ...>
...
<value/>
</field>
which would indicate that other values are possible?
Or
...
<value from="2" to="inf" description=""/>
etc. etc.
We should also check native QF whether it works there.
Those are both good ideas, I think I prefer the <value enum="..."> solution, as it would work for non-integer enums.
Another possibility is have a
<value constant="0" description ="FULL_BOOK"/>
<value constant="1" description ="TOP_OF_BOOK"/>
indicating this isn't an enum, it was just a special constant value. However, this fails to encapsulate the knowledge that values <0 are illegal. Checking with native QF is a good idea, we should keep the files the same ideally.
I haven't looked since this issue was raised, but the QuickFIX C++ spec files were also inconsistent for this enum. They might have been changed since I looked last so I'll look again when I have some time.
It looks like the QuickFIX C++ spec files comment the enums for 4.2-4.4. The only issue I can think of for uncommenting the fields is that it may cause validation to start failing with existing installations. Is the lack of constant generation the only problem with the commented fields?
I've decided to comment the enums in all versions. I've updated the 1.0.x branch and the trunk.
A file with some extra space removed before the close of XML elements, so the file is consistent with the FIX42.xml and FIX43.xml files