Imported from previous forum
[ original email was from Matt Simpson - msimpson@cme.com ]
We spent some time discussing this question in today’s MDOWG meeting. My interpretation of the spec is that a pmap slot is required for sequence length regardless of whether it is specified as implicit or explicit.
The td:length element corresponds to a field which can be optionally defined in a message structure. The spec says “A sequence can be mandatory or optional. An optional sequence means that the length field is optional.” An optional length field needs to be represented by a slot in the pmap. If the length field is not present, the slot in the pmap will be set to ‘off’. If the length is present pmap slot will be set to ‘on’.
Whether the length is defined as implicit or explicit only has an impact on the template in that it may or may not need to carry a name for the length field which can then be mapped to a FIX NumInGroup field.
I’d like to get confirmation of this from the group. If this is the case, it is worth putting a clarification in the spec which states that a use of the Sequence Length field requires a slot in the pmap. Thanks
The pmap and NULL utilization of a sequence length preamble is the same as for a uInt32 field:
If the field is optional, a nullable encoding is used. If the field has a field operator requiring a slot in the pmap, the field has a slot in the pmap.
This means that a optional sequence is encoded as a NULL unsigned intger (one byte: 0x80).
You’re right that the presence of a td:length element does not change the pmap utilization in it self. A field operator specified as a child of the td:length element may however require a slot in the pmap.
<td:sequence name=“Examples” presence=“optional”>
<td:length name=“NoOfExamples”/>
…
</td:sequence>
The above case would not require a slot in the pmap. But this one would (since the copy operator requires a slot):
<td:sequence name=“Examples” presence=“optional”>
<td:length name=“NoOfExamples”> td:copy/ </td:length>
…
</td:sequence>
Both examples would use NULL to indicate absence of the sequence.
/David
We spent some time discussing this question in today’s MDOWG meeting. My
interpretation of the spec is that a pmap slot is required for sequence
length regardless of whether it is specified as implicit or explicit.The td:length element corresponds to a field which can be optionally
defined in a message structure. The spec says “A sequence can be
mandatory or optional. An optional sequence means that the length field
is optional.” An optional length field needs to be represented by a
slot in the pmap. If the length field is not present, the slot in the
pmap will be set to ‘off’. If the length is present pmap slot will be
set to ‘on’.Whether the length is defined as implicit or explicit only has an impact
on the template in that it may or may not need to carry a name for the
length field which can then be mapped to a FIX NumInGroup field.I’d like to get confirmation of this from the group. If this is the
case, it is worth putting a clarification in the spec which states that
a use of the Sequence Length field requires a slot in the pmap. Thanks
[ original email was from Matt Simpson - msimpson@cme.com ]
David, thanks. Let me put this into the context of a FIX market data message to illustrate the requirement.
Case1 - The MDEntry repeating group is defined as a mandatory sequence without the use of an operator on td:length so that a bit in the pmap will NOT be necessary since the length field must always be present.
Case2 - The MDEntry repeating group is defined as an optional sequence without the use of an operator on td:length so that a bit in the pmap will NOT be necessary since the length field will either be present or represented as NULL if not present
Case3 - The MDEntry repeating group is defined as a mandatory or optional sequence with the use of an operator on td:length so that a bit in the pmap WILL be necessary since the length field may or may not be present.
Finally, when a modeling a FIX message it is generally desirable to include the repeating count field as part of the encoded data and there is little value in using field encoding. Thus, it can be defined as in Case1 above meaning that a pmap slot is not necessary.
The pmap and NULL utilization of a sequence length preamble is the same
as for a uInt32 field:If the field is optional, a nullable encoding is used. If the field
has a field operator requiring a slot in the pmap, the field has a
slot in the pmap.This means that a optional sequence is encoded as a NULL unsigned intger
(one byte: 0x80).You’re right that the presence of a td:length element does not change
the pmap utilization in it self. A field operator specified as a child
of the td:length element may however require a slot in the pmap.<td:sequence name=“Examples” presence=“optional”> <td:length
name=“NoOfExamples”/> … </td:sequence>The above case would not require a slot in the pmap. But this one would
(since the copy operator requires a slot):<td:sequence name=“Examples” presence=“optional”> <td:length
name=“NoOfExamples”> td:copy/ </td:length> … </td:sequence>Both examples would use NULL to indicate absence of the sequence.
/David
We spent some time discussing this question in today’s MDOWG meeting.
My interpretation of the spec is that a pmap slot is required for
sequence length regardless of whether it is specified as implicit or
explicit.The td:length element corresponds to a field which can be optionally
defined in a message structure. The spec says “A sequence can be
mandatory or optional. An optional sequence means that the length
field is optional.” An optional length field needs to be represented
by a slot in the pmap. If the length field is not present, the slot in
the pmap will be set to ‘off’. If the length is present pmap slot will
be set to ‘on’.Whether the length is defined as implicit or explicit only has an
impact on the template in that it may or may not need to carry a
name for the length field which can then be mapped to a FIX
NumInGroup field.I’d like to get confirmation of this from the group. If this is the
case, it is worth putting a clarification in the spec which states
that a use of the Sequence Length field requires a slot in the
pmap. Thanks
Yep, the cases are all OK. Whether a field operator on the length preamble is beneficial or not is situation dependent even in the FIX case. But if you want to start out simple with no slot in the pmap, the easiest way is just to not specify any operator at all for the length preamble.
/David
Case1 - The MDEntry repeating group is defined as a mandatory sequence
without the use of an operator on td:length so that a bit in the pmap
will NOT be necessary since the length field must always be present.Case2 - The MDEntry repeating group is defined as an optional sequence
without the use of an operator on td:length so that a bit in the pmap
will NOT be necessary since the length field will either be present or
represented as NULL if not presentCase3 - The MDEntry repeating group is defined as a mandatory or
optional sequence with the use of an operator on td:length so that a
bit in the pmap WILL be necessary since the length field may or may not
be present.Finally, when a modeling a FIX message it is generally desirable to
include the repeating count field as part of the encoded data and there
is little value in using field encoding. Thus, it can be defined as in
Case1 above meaning that a pmap slot is not necessary.
[ original email was from Darshan Khedekar - darshan.khedekar.ext@deutsche-boerse.com ]
Hi
In this context I have the following cases
Case 1: Constant value as is
NO PREMAP BIT REQUIRED
Case 2: Implicit value as in
NO PREMAP BIT REQUIRED
Case 3: Copy value as in
YES PREMAP BIT IS REQUIRED
That means, if I have only the above cases, my pre-map has only bits for “Copy” fields as I donot have any presence=“optional” fields
Thanks and Regards
Darshan
Yep, the cases are all OK. Whether a field operator on the length
preamble is beneficial or not is situation dependent even in the FIX
case. But if you want to start out simple with no slot in the pmap,
the easiest way is just to not specify any operator at all for the
length preamble./David
Case1 - The MDEntry repeating group is defined as a mandatory sequence
without the use of an operator on td:length so that a bit in the pmap
will NOT be necessary since the length field must always be present.Case2 - The MDEntry repeating group is defined as an optional sequence
without the use of an operator on td:length so that a bit in the pmap
will NOT be necessary since the length field will either be present or
represented as NULL if not presentCase3 - The MDEntry repeating group is defined as a mandatory or
optional sequence with the use of an operator on td:length so that a
bit in the pmap WILL be necessary since the length field may or may
not be present.Finally, when a modeling a FIX message it is generally desirable to
include the repeating count field as part of the encoded data and
there is little value in using field encoding. Thus, it can be defined
as in Case1 above meaning that a pmap slot is not necessary.
[ original email was from Matt Simpson - msimpson@cme.com ]
Darshan -
You are correct that only Case 3 would use a pmap slot. Please note that these pmap rules apply to v1.1 and that the implicit operator has been removed from v1.1. I would recommend that you use features from a single version of the spec.
Hi
In this context I have the following cases Case 1: Constant value as is
NO PREMAP BIT
REQUIRED Case 2: Implicit value as in
NO PREMAP BIT REQUIRED Case 3: Copy value as in
YES PREMAP BIT IS REQUIREDThat means, if I have only the above cases, my pre-map has only bits for
“Copy” fields as I donot have any presence=“optional” fieldsThanks and Regards Darshan
Yep, the cases are all OK. Whether a field operator on the length
preamble is beneficial or not is situation dependent even in the FIX
case. But if you want to start out simple with no slot in the pmap,
the easiest way is just to not specify any operator at all for the
length preamble./David
Case1 - The MDEntry repeating group is defined as a mandatory
sequence without the use of an operator on td:length so that a bit
in the pmap will NOT be necessary since the length field must always
be present.Case2 - The MDEntry repeating group is defined as an optional
sequence without the use of an operator on td:length so that a bit
in the pmap will NOT be necessary since the length field will either
be present or represented as NULL if not presentCase3 - The MDEntry repeating group is defined as a mandatory or
optional sequence with the use of an operator on td:length so that a
bit in the pmap WILL be necessary since the length field may or may
not be present.Finally, when a modeling a FIX message it is generally desirable to
include the repeating count field as part of the encoded data and
there is little value in using field encoding. Thus, it can be
defined as in Case1 above meaning that a pmap slot is not necessary.
[ original email was from Darshan Khedekar - darshan.khedekar.ext@deutsche-boerse.com ]
Hi Matt,
I referred to the link http://www.fixprotocol.org/documents/2811/FAST%20Specification%201.x.05.pdf for FAST Specification. If there is an updated version, please paste the link here.
Thanks and Regards
Darshan
Darshan -
You are correct that only Case 3 would use a pmap slot. Please note that
these pmap rules apply to v1.1 and that the implicit operator has been
removed from v1.1. I would recommend that you use features from a single
version of the spec.Hi
In this context I have the following cases Case 1: Constant value as
is NO PREMAP
BIT REQUIRED Case 2: Implicit value as in
NO PREMAP BIT REQUIRED Case 3: Copy value as in YES PREMAP BIT IS REQUIREDThat means, if I have only the above cases, my pre-map has only bits
for “Copy” fields as I donot have any presence=“optional” fieldsThanks and Regards Darshan
Yep, the cases are all OK. Whether a field operator on the length
preamble is beneficial or not is situation dependent even in the FIX
case. But if you want to start out simple with no slot in the pmap,
the easiest way is just to not specify any operator at all for the
length preamble./David
Case1 - The MDEntry repeating group is defined as a mandatory
sequence without the use of an operator on td:length so that a bit
in the pmap will NOT be necessary since the length field must
always be present.Case2 - The MDEntry repeating group is defined as an optional
sequence without the use of an operator on td:length so that a bit
in the pmap will NOT be necessary since the length field will
either be present or represented as NULL if not presentCase3 - The MDEntry repeating group is defined as a mandatory or
optional sequence with the use of an operator on td:length so that
a bit in the pmap WILL be necessary since the length field may or
may not be present.Finally, when a modeling a FIX message it is generally desirable
to include the repeating count field as part of the encoded data
and there is little value in using field encoding. Thus, it can be
defined as in Case1 above meaning that a pmap slot is not
necessary.