Imported from previous forum
[ original email was from Jim Northey - jnorthey@jandj.com ]
Early on I recall some discussions about each group having its own template ID. Was this every formalized or discussed as part of what the consensus feels is in FAST 1.0?
Reason for these questions - just trying to tighten up the existing specification a bit.
There was little discussion on this and the issue wasn’t resolved.
The current TE spec section 2.3.2 says:
"Each group has:
- A presence map if at least one entry in the Group has a
default value; - A TemplateID field if the group layout cannot be statically
deduced; meaning that the TemplateID is not fixed but can
vary from message to message. - A size field if the template specifies so.
…"
My intent when I wrote this was to allow what is called
“variant records” in some programming languages.
(The repeating group would be like a container that
supports heterogeneous types)
Let’s say you want to send a list of messages with
different types (and layouts) and consequently different
TemplateIDs. A repeating group that allows a TemplateID
for each entry would then be able to encode these messages.
Anyway, this construct needs some further discussion.
Thx,
Rolf
Early on I recall some discussions about each group having its own
template ID. Was this every formalized or discussed as part of what
the consensus feels is in FAST 1.0?Reason for these questions - just trying to tighten up the existing
specification a bit.
David Rosenborg pointed out to me (the obvious) that even though
you would want to use different templates in a repeating group
it isn’t necessarily the case that you’ll end up with different
types on the application level (e.g. different representations
for the same application level message). The repeating group
(i.e. the container) would not store heterogeneous items, just
different representations of the same application type.
Thx,
Rolf
There was little discussion on this and the issue wasn’t resolved.
The current TE spec section 2.3.2 says: "Each group has:
- A presence map if at least one entry in the Group has a default value;
- A TemplateID field if the group layout cannot be statically deduced;
meaning that the TemplateID is not fixed but can vary from message
to message.- A size field if the template specifies so. …"
My intent when I wrote this was to allow what is called “variant
records” in some programming languages.(The repeating group would be like a container that supports
heterogeneous types)Let’s say you want to send a list of messages with different types
(and layouts) and consequently different TemplateIDs. A repeating
group that allows a TemplateID for each entry would then be able to
encode these messages.Anyway, this construct needs some further discussion.
Thx, Rolf
Early on I recall some discussions about each group having its own
template ID. Was this every formalized or discussed as part of what
the consensus feels is in FAST 1.0?Reason for these questions - just trying to tighten up the existing
specification a bit.
[ original email was from Jim Northey - jnorthey@jandj.com ]
We had some discussions on this. For FAST 1.0 - I think the consensus is that repeating groups (nested or not) would not include separate TIDs groups within a message. The view is that this will give us common simple implementation approach for initial installations. Later, as we learn more about using FAST in production applications, the value and implications in having TIDs within groups will become more apparent.
Is everyone cool with FAST 1.0 functionality including nested repeating groups that do not support separate template ids for each group?
David Rosenborg pointed out to me (the obvious) that even though you
would want to use different templates in a repeating group it isn’t
necessarily the case that you’ll end up with different types on the
application level (e.g. different representations for the same
application level message). The repeating group
(i.e. the container) would not store heterogeneous items, just different
representations of the same application type.Thx, Rolf
There was little discussion on this and the issue wasn’t resolved.
The current TE spec section 2.3.2 says: "Each group has:
- A presence map if at least one entry in the Group has a default
value;- A TemplateID field if the group layout cannot be statically deduced;
meaning that the TemplateID is not fixed but can vary from message
to message.- A size field if the template specifies so. …"
My intent when I wrote this was to allow what is called “variant
records” in some programming languages.(The repeating group would be like a container that supports
heterogeneous types)Let’s say you want to send a list of messages with different types
(and layouts) and consequently different TemplateIDs. A repeating
group that allows a TemplateID for each entry would then be able to
encode these messages.Anyway, this construct needs some further discussion.
Thx, Rolf
Early on I recall some discussions about each group having its own
template ID. Was this every formalized or discussed as part of what
the consensus feels is in FAST 1.0?Reason for these questions - just trying to tighten up the existing
specification a bit.
[ original email was from Jim Northey - jnorthey@jandj.com ]
I would also think that eventually we will want template ids withine repeating groups to support templates for FIX components - such as the instrument block, parties block, etc.