[Quickfix-developers] Discrepancies in FIX44.xml?

[James W. <wi...@wi...>]

 Folks,

   I'm working with the FIX44.xml specification document off the
QuickFIX site and I've spotted what seem like discrepancies between
it and the FIX4.4 spec at fixprotocol.org.  The MDEntryRefID "group"
under MarketDataIncrementalRefresh doesn't appear to jibe with what
is defined in the fixprotocol.org FIXIimate documentation.  Is this
a "group" that isn't a repeating group, but just an organizational
convenience?  There is no "NoMDEntryRefID" defined in FIXimate to
indicate that MDEntryRefID is a repeating group.  FIXimate defines
it as a string field.  What's up, here?

   Secondly, the FIX header clearly specifies a field "NoHops" to
indicate the number of "HopCompID" groups, but FIX44.xml has:
...
    <field name="LastMsgSeqNumProcessed" required="N" />
    <group name="HopCompID" required="N">
      <field name="HopCompID" required="N" />
      <field name="HopSendingTime" required="N" />
      <field name="HopRefID" required="N" />
    </group>
</header>
...
   A typo?  Or is this deliberate?  Shouldn't it be instead:
...
    <field name="LastMsgSeqNumProcessed" required="N" />
    <group name="NoHops" required="N">
      <field name="HopCompID" required="N" />
      <field name="HopSendingTime" required="N" />
      <field name="HopRefID" required="N" />
    </group>
</header>
...

   Finally, the "News" message type defines the group number field
for "Text" as "NoLinesOfText" but FIX44.xml contains:
...
      <group name="LinesOfText" required="Y">
        <field name="Text" required="Y" />
        <field name="EncodedTextLen" required="N" />
        <field name="EncodedText" required="N" />
      </group>
...
   So, shouldn't it be:
...
      <group name="NoLinesOfText" required="Y">
        <field name="Text" required="Y" />
        <field name="EncodedTextLen" required="N" />
        <field name="EncodedText" required="N" />
      </group>
...

   That said, I've gotten an enormous amount of benefit from these
spec files and want to send profuse thanks to whomever built them
and then made them available!

regards,
Jim Wiggs