PUBLIC COMMENT PERIOD - FAST 1.2 Extension Proposal

, ,
1

Imported from previous forum

2

The Global Technical Committee has reviewed and preliminary approved the FAST 1.2 Extension Proposal. The document now enters a 7 day public comment period in which public review and feedback is encouraged. Once the Public Comment period closes, the Global Technical Governance Board will meet to review public comments before final approval.
Please post feedback, comments, and questions as replies to this discussion thread.

A link to the proposal can be found at:

http://www.fixprotocol.org/documents/4322/FAST%201%202%20Extension%20Proposal%20v10.doc

The public comment period ends on January 28, 2009.

3

I missed the public comment period on the FAST 1.2 Extension Proposal, but I do have a comment/observation/question.

In describing the Set (multi-value field) the document says:

If the field is nullable, then NULL is assigned the encoded value 0
(zero) analogously with how nullable integers are defined.

Is it possible to distinguish between the empty set and a set which is not present? This would be analogous to distinguishing between an empty string and a string which is not present, or between a zero integer and an integer that is not present.

Or to ask this another way:

Nullable integer: 0x80->NULL; 0x81->0
Nullable string: 0x80->NULL; 0x0,0x80->empty string
Nullable Set: 0x80->NULL; ???->empty set.

Dale

4

I do not understand the semantic you want to convey with an empty set. I understand the need for a zero integer or an empty string as representing an actual valid value. The set is meant to express one or more values from a list of values. An example are the FIX data types MultipleCharValue and MultipleStringValue. If the field is present, it cannot be empty, i.e. at least one value needs to be specified.

What is the use case you are trying to cover here?

Regards,
Hanno.

I missed the public comment period on the FAST 1.2 Extension Proposal,
but I do have a comment/observation/question.

In describing the Set (multi-value field) the document says:

If the field is nullable, then NULL is assigned the encoded value 0
(zero) analogously with how nullable integers are defined.

Is it possible to distinguish between the empty set and a set which is
not present? This would be analogous to distinguishing between an empty
string and a string which is not present, or between a zero integer and
an integer that is not present.

Or to ask this another way:

Nullable integer: 0x80->NULL; 0x81->0 Nullable string: 0x80->NULL; 0x0,0x80-

empty string Nullable Set: 0x80->NULL; ???->empty set.

Dale

5

[ original email was from Mikael Brannstrom - m.brannstrom@ngm.se ]
I think Dale has a point here.

I think there is the same need for the empty set as for the empty string, the empty byte array or the empty sequence. Otherwise the set would be the only field in FAST where the ‘empty value’/zero is not valid, and the mandatory and optional encoding are the same.

The added cost of being able to distinguish between the empty set and null would only affect the nullable encoding (perhaps add one bit for the empty set). If you don’t want the added cost, then use a mandatory set.

/Mikael

I do not understand the semantic you want to convey with an empty set. I
understand the need for a zero integer or an empty string as
representing an actual valid value. The set is meant to express one or
more values from a list of values. An example are the FIX data types
MultipleCharValue and MultipleStringValue. If the field is present, it
cannot be empty, i.e. at least one value needs to be specified.

What is the use case you are trying to cover here?

Regards, Hanno.

I missed the public comment period on the FAST 1.2 Extension Proposal,
but I do have a comment/observation/question.

In describing the Set (multi-value field) the document says:

If the field is nullable, then NULL is assigned the encoded value 0
(zero) analogously with how nullable integers are defined.

Is it possible to distinguish between the empty set and a set which is
not present? This would be analogous to distinguishing between an
empty string and a string which is not present, or between a zero
integer and an integer that is not present.

Or to ask this another way:

Nullable integer: 0x80->NULL; 0x81->0 Nullable string: 0x80->NULL; 0x0,0x80-

empty string Nullable Set: 0x80->NULL; ???->empty set.

Dale

6

I do not understand the semantic you want to convey with an empty set. I
understand the need for a zero integer or an empty string as
representing an actual valid value. The set is meant to express one or
more values from a list of values. An example are the FIX data types
MultipleCharValue and MultipleStringValue. If the field is present, it
cannot be empty, i.e. at least one value needs to be specified.

The use case is not so much the existing FIX standard which is unable to express quite a few concepts, but the future uses of FAST.

FIX does not allow expressing an empty string (at least not legally although certain non-conforming implementations I could mention…)[see note below for a reference]

But FAST does support an empty string. It also supports strings with non-printable characters – another no-no in the FIX world.

Likewise even though the current FIX usage of a multi-valued field does not allow a set to be empty for exactly the same reason it does not allow an empty string, an empty set is a well defined concept, and is quite different from a NULL set. FAST should provide support for this in order to maintain it’s general usefulness. I believe that such support could be included without incurring any additional cost for applications that did not need this capability, for example by encoding a null set as 0x80, and an empty set as 0x00,0x80.

Dale

Reference: My statement that FIX does not support an empty string is based on the following paragraph in FIX 5.0 volume 1:

What is the use case you are trying to cover here?

Regards, Hanno.

I missed the public comment period on the FAST 1.2 Extension Proposal,
but I do have a comment/observation/question.

In describing the Set (multi-value field) the document says:

If the field is nullable, then NULL is assigned the encoded value 0
(zero) analogously with how nullable integers are defined.

Is it possible to distinguish between the empty set and a set which is
not present? This would be analogous to distinguishing between an
empty string and a string which is not present, or between a zero
integer and an integer that is not present.

Or to ask this another way:

Nullable integer: 0x80->NULL; 0x81->0 Nullable string: 0x80->NULL; 0x0,0x80-

empty string Nullable Set: 0x80->NULL; ???->empty set.

Dale

7

I did not want to restrict the use cases to what FIX provides/permits. The extensions of FAST have been driven by use cases where people wanted to express something in a more efficient way than currently possible. So far, I only see a technical reason of completeness to introduce an empty set, i.e. because other data types also provide the concept of an empty value in addition to the NULL value. This may be a valid reason but I was hoping for some kind of business justification as well. I am not against your suggestion, just trying to understand its use.

Regards,
Hanno.

The use case is not so much the existing FIX standard which is unable to
express quite a few concepts, but the future uses of FAST.

FIX does not allow expressing an empty string (at least not legally
although certain non-conforming implementations I could mention…)[see
note below for a reference]

But FAST does support an empty string. It also supports strings with non-
printable characters – another no-no in the FIX world.

Likewise even though the current FIX usage of a multi-valued field does
not allow a set to be empty for exactly the same reason it does not
allow an empty string, an empty set is a well defined concept, and is
quite different from a NULL set. FAST should provide support for this in
order to maintain it’s general usefulness. I believe that such support
could be included without incurring any additional cost for applications
that did not need this capability, for example by encoding a null set as
0x80, and an empty set as 0x00,0x80.

Dale

Reference: My statement that FIX does not support an empty string is
based on the following paragraph in FIX 5.0 volume 1:

[quote] Each message is constructed of a stream of =
fields with a field delimiter between fields in the stream. Tags are
of data type TagNum. All tags must have a value specified. Optional
fields without values should simply not be specified in the FIX
message. A Reject message is the appropriate response to a tag with no
value. [/quote]

8

Nullable sets are implemented analogously with integers:
0x80 = NULL
0x81 = empty set

A set can be viewed as a (possibly very large) integer. 1 (one) is added to the representation at serialization time and 1 (one) is subtracted during de-serialization.

(On a side-note: you have to implement multi precision add with carry and subtract with borrow to support the general case with sets that are larger than your biggest internal integer representation which most likely is u64. I personally view this as a fringe benefit :slight_smile:

Best,
Rolf

I missed the public comment period on the FAST 1.2 Extension Proposal,
but I do have a comment/observation/question.

In describing the Set (multi-value field) the document says:

If the field is nullable, then NULL is assigned the encoded value 0
(zero) analogously with how nullable integers are defined.

Is it possible to distinguish between the empty set and a set which is
not present? This would be analogous to distinguishing between an empty
string and a string which is not present, or between a zero integer and
an integer that is not present.

Or to ask this another way:

Nullable integer: 0x80->NULL; 0x81->0 Nullable string: 0x80->NULL; 0x0,0x80-

empty string Nullable Set: 0x80->NULL; ???->empty set.

Dale