FIXTradingCommunity / fix-simple-binary-encoding

A FIX standard for binary message encoding
Other
263 stars 69 forks source link

Remove deprecated attributes from v1.0 RC2 #44

Closed donmendelson closed 6 years ago

donmendelson commented 7 years ago

In early drafts, XML attributes epoch and timeUnit were proposed. However, no other epoch was ever defined besides the UNIX attribute. TimeUnit is handled is handled in the wire format rather than just in metadata. Therefore, the two XML attributes may be removed in version 2.0 of the schema.

RFrenkel commented 7 years ago

Hi Don, Does this change require application using a default TimeUnit to specify TimeUnit on the wire nevertheless? For example we are currently using nanoseconds since Unix epoch consistently across all messages and schemas for all our UTCTimestamps. With the proposed change would we be required to encode nanoseconds as enumerated TimeUnit and send it on the wire with every UTC Timestamp? This would create a waste of bytes on the wire which we would want to avoid.

donmendelson commented 7 years ago

Rosa, see Time and Date Encoding in section 2 of v1.0 Standard. It shows how the timeUnit can either be sent on the wire or it can be set as a constant. This enhancement was made in v1.0 RC3.

This example is given of a constant timeUnit--8 bytes are sent on the wire:

<composite name="UTCTimestampNanos" description="UTC timestamp with nanosecond precision" semanticType="UTCTimestamp" >
    <type name="time" primitiveType="uint64" />
    <type name="unit" primitiveType="uint8" presence="constant" valueRef="TimeUnit.nanosecond" />
</composite>
RFrenkel commented 7 years ago

I understand that constant is always an option, if the value is not changing and no need to send it on the wire, but is there an option in v.1.0 to keep UTCTimestamp as simple binary type (not a composite) for default TimeUnits? I think for the applications that already implemented SBE based on RC2 we should have a way to keep things simple and not unnecessarily impact our customers with template changes that default to the same data on the wire.

RFrenkel commented 7 years ago

Hi again Don, Is v.1 xml validation going to fail on semantic type UTCTimestamp used with uInt64 type? Ex:

RFrenkel commented 7 years ago

field name="LastUpdateTime" id="779" type="uInt64" description="Timestamp of when the instrument was last added, modified or deleted" offset="6" semanticType="UTCTimestamp"

donmendelson commented 7 years ago

@RFrenkel , if you are keeping the time unit constant at nanoseconds, then there will be no change to the wire format that you have been using. It will still be 8 bytes on the wire. However, there would be slight change to the XML metadata. You would use the composite type as shown above rather than just the primitive type.

adkapur commented 7 years ago

Therefore, the two XML attributes may be removed in version 2.0 of the schema.

Don could you please specify which two attributes are being removed?

donmendelson commented 7 years ago

To be removed:

<xs:attribute name="epoch" type="xs:string" default="unix"/>
<xs:attribute name="timeUnit" type="xs:string" default="nanosecond">

No alternative was every offered for epoch, so it seems pointless. The timeUnit attribute lives on as a composite type member for UTCTimestamp.