Modeling components and repeating groups in Template Definition

, ,
1

Imported from previous forum

2

[ original email was from Henrik Johansson - henrik.johansson@omxgroup.com ]
Hi,

What is the proper way to model a FIX Component in the FAST template? The problem I am currently facing is that the presence of some fields of the component inherits from the presence attribute of the component in a specific message in the FIX Spec. Ex: LegSymbol (Tag 600) in the InstrumentLeg Component. When modeling the components as templates, I find it difficult to express this relation.

I have the same problem when I model a repeating group whose presence is mandatory in some messages and optional in other (i.e NoXXX shall always be set and always to >0 in some messages, while it is ok to omit the group in other.

Thanks,
Henrik

3

[ original email was from Matt Simpson - msimpson@cme.com ]
Assuming that you’re using the xml syntax to define templates, the Group Field Instruction found in the FAST Template Definition Specification will allow you to specify FIX components in your template and indicate the whether that component is present or not. From the spec: “The main purpose of the group field instruction is to enable a single bit in the presence map to indicate the presence of a whole group of fields.”

Note that this spec will soon be supplanted by a new FAST v1.1 spec which combines field and transfer encoding while providing the associated template definition syntax. The concept of grouping will continue to be supported.

http://www.fixprotocol.org/documents/2374/FAST%20Template%20Definition%20Specification%200.38.pdf

Hi,

What is the proper way to model a FIX Component in the FAST template?
The problem I am currently facing is that the presence of some fields of
the component inherits from the presence attribute of the component in a
specific message in the FIX Spec. Ex: LegSymbol (Tag 600) in the
InstrumentLeg Component. When modeling the components as templates, I
find it difficult to express this relation.

I have the same problem when I model a repeating group whose presence is
mandatory in some messages and optional in other (i.e NoXXX shall always
be set and always to >0 in some messages, while it is ok to omit the
group in other.

Thanks, Henrik

4

[ original email was from Henrik Johansson - henrik.johansson@omxgroup.com ]
If I understand the Template Definition Specification correct, usage of groups will not resolve my wish to have only 1 ‘definition’ of InstrumentLeg since each field instruction has a presence attribute. If omitted the field is mandatory.

If the presence could have the value ‘inherited’ it could then be defined as it inherits the groups presence value. See below:

<template name=“InstrumentLeg” id=“222”>
<string name=“LegSymbol” presence=“inherited” charset=“unicode”><copy /></string>
<string name=“LegIssuer” charset=“unicode”><copy /></string>
…
</template>

<template name=“MultiLegOrderLegs” id=“229”>
<sequence name=“MultiLegOrderLegs”>
<length name=“NoLegs” />
<group name=“aGroup” id=“253” presence=“mandatory”>
<templateRef name=“InstrumentLeg” />
</group>
…
</sequence>
</template>

<template name=“Dummy” id=“230”>
<sequence name=“MultiLegOrderLegs”>
<length name=“NoLegs” />
<group name=“aGroup2” presence=“optional”>
<templateRef name=“InstrumentLeg” />
</group>
…
</sequence>
</template>

or in the repeating group case:

<template name=“SideCrossOrdModGrp” id=“224”>
<sequence name=“SideCrossOrdModGrp” presence=“inherited”>
<length name="NoSides/>
…
</sequence>
</template>

Referenced from either

 &lt;template name="NewOrderCross" id="28"&gt;
  ...
  &lt;templateRef name="SideCrossOrdModGrp" presence="mandatory"/&gt; &lt;!-- NOTE: presence attribute here i not allowed, according to .xsd --&gt;
  ...
 &lt;/template&gt;

or
<template name=dummy" id=“28”>
<group name=“aGroup3” presence=“mandatory”>
<templateRef name=“SideCrossOrdModGrp”/>
</group>
…
</template>

5

[ original email was from David Rosenborg - David.Rosenborg@pantor.com ]
> If I understand the Template Definition Specification correct, usage of

groups will not resolve my wish to have only 1 ‘definition’ of
InstrumentLeg since each field instruction has a presence attribute. If
omitted the field is mandatory.

The general answer is that FAST doesn’t support parameterized templates. Though I don’t think it’s needed for your example with groups. Isn’t it the case that either both Symbol and Issuer appear or none of them? If that is the case the following would do what you want:

... ... ...

With sequences you’d have to maintain a mandatory and an optional version.

The good news is that if you find your administration of templates unwieldy because of this you’re not out of luck. Since the feature you’re looking for can be expressed as a syntactical transformation, I’d recommend that you add a transformation step: write your templates with some additions for template parameterization as you suggest and use for example XSLT to reslove the presence attributes to produce a FAST compliant set of templates.

/David

6

[ original email was from Henrik Johansson - henrik.johansson@omxgroup.com ]
Unfortunately Components in FIX are not specified that either all or none appears.

In the InstrumentLeg component block (4.4 Spec vol 1 page 46) LegSymbol has the req’d value ‘***’ which refers back to the req’d setting for the InstrumentLeg component block in the message definition. All other fields in the component are optional.

So, I guess I will have to stick with maintaining a mandatory and an optional version in these cases.

/Henrik

7

[ original email was from David Rosenborg - David.Rosenborg@pantor.com ]
> Unfortunately Components in FIX are not specified that either all or

none appears.

The primary intention with FAST templates is that you model them after your particular usage pattern rather than after the full capabilities of the message types. It’s of course possible to create something refered to as a set of “identity templates” that would allow any instance of a particular message type to be encoded using the same template. However, such a set of templates would in many cases yield poor compression and thus defeat the purpose of using FAST in the first place.

In the InstrumentLeg component block (4.4 Spec vol 1 page 46) LegSymbol
has the req’d value ‘***’ which refers back to the req’d setting for the
InstrumentLeg component block in the message definition. All other
fields in the component are optional.

If you use groups and mark the LegSymbol as mandatory and all other fields as optional, you’ll have the same effect:

Assuming the following template:

...

In the following case, the group is mandatory and hence the LegSymbol must appear in the stream, all other fields in the group are optional.

In the following case, the group is optional. When the group is absent, none of its fields appear in the stream regardless of their individual presence attributes. When the group is present in the stream the presence attributes of the fields must be followed and a LegSymbol must appear.

/David

8

[ original email was from David Rosenborg - David.Rosenborg@pantor.com ]

I have the same problem when I model a repeating group whose presence is
mandatory in some messages and optional in other (i.e NoXXX shall always
be set and always to >0 in some messages, while it is ok to omit the
group in other.

The >0 constraint cannot be expressed in FAST, but optionality can:

Mandatory sequence:

…

Optional sequence:

…

Note that a mandatory sequence is allowed to have zero length.

/David

9

[ original email was from Henrik Johansson - henrik.johansson@omxgroup.com ]
I see from the Template Specification (ver 0.38) that there is an open issue that “There should probably be a limit on the maximum length allowed.”

Maybe this issue can re resolved as:
<sequence name=“XXX”> <length name=“NoXXX” min=“x” max=“y”/> … </sequence>

An other more general question is how much of FIX shall be possible to express in FAST? Is the goal that everything shall be possible to express in FAST? Or is the above an example of something that is good enough to resolve in the businesslayer and ignore that validation in FAST?

/Henrik

10

[ original email was from David Rosenborg - David.Rosenborg@pantor.com ]
The purpose of FAST templates is to express properties that affect compression and processing performance. There is no intention to provide means for specifying application constraints in general.

The open issue you’re referring to is about specifying a fixed upper limit that would help implementations detecting abnormal sequence lengths. My guess is that such a limit will not be specified but that implmentations are encourage to add their own limits.

/David

I see from the Template Specification (ver 0.38) that there is an
open issue that “There should probably be a limit on the maximum
length allowed.”

Maybe this issue can re resolved as: …

An other more general question is how much of FIX shall be possible
to express in FAST? Is the goal that everything shall be possible to
express in FAST? Or is the above an example of something that is
good enough to resolve in the businesslayer and ignore that
validation in FAST?

/Henrik

11

The purpose of FAST templates is to express properties that affect
compression and processing performance.

I naively supposed that nothing about FAST templates (or FAST in general) is intended to address processing performance. Which aspect of templates could boost processing performance?

12

The purpose of FAST templates is to express properties that affect
compression and processing performance.

I naively supposed that nothing about FAST templates (or FAST in
general) is intended to address processing performance.
Which aspect of templates could boost processing performance?

Use of operators, grouping of fields, order of fields, …

Templates are used to specify how a FAST encoder (and decoder)
should process messages.

For example, let’s assume you have an ASCII fixed record protocol
that you’d want to encode using FAST.

It would be possible to specify an “identity” template with no
operators (no copy coding etc.) and string fields throughout.

Such a template would possibly yield some compression as a result
of leading spaces or zeroes in numeric fields and trailing spaces
in alpha fields. Other than that you would not get any benefit
from data affinities binary numeric representation etc.

By adding operators and numeric data types, you would be able to
get better compression at the cost of slightly larger overhead
in encoding and decoding your messages.

Hope this answers your question.

/Rolf