Transport Independance Framework not so Independent

, ,
1

Imported from previous forum

2

At this point I guess this more of an editorial/dispositional comment, but in my opinion the cut between the transport and application layer isn’t that clean.

The FIX Transport 1.1 spec defines the layout of the Standard Header and the session messages. In doing so, it refers to fields that are defined in the, well, application layer specification. So theoretically, given a particular tag in the FIXT.1.1 Standard Header, the definition of this tag can only be fully known when you know what application protocol you’re using, which is when you’ve read (or detect the absence of) the ApplVerID, which could very well be at the last field of the header. A little bit too tangled up in my opinion.

So does this matter in practice? Yes, if you develop generic FIX software that tries to follow the specs, using the same ontology and wants to be future proof, it does matter. The specs might work for human consumption, but imposes (unnecessary) challenges when you put them down in more formal code.

Kind Regards,
David

3

[ original email was from Steven Grossman - steven.grossman@transacttools.net ]
Hi David,

I completely agree. This is something that the GTC FIX 5.0 Usage Subcommittee (http://www.fixprotocol.org/committees/fix5.0usage) is currently addressing.

Our current proposal treats the messages, groups, and fields defined in the FIX 5.0 specification as a data model for business content. Fields that do not convey business content will be moved out of the FIX 5.0 specification and into the FIXT specification for the sole use of FIXT.

The following document outlines the current proposal - http://www.fixprotocol.org/documents/3510/FIX5_Components_v0.2.doc (you may need to be a member of the group to see this document – let me know if you have trouble getting it).

I would welcome your involvement in this group to help sort out these issues.

  • steven
4

Ok, sounds like we’re thinking in the same direction.

Here’s my current list of things that I think need to be addressed
(I wasn’t able to follow the document link so the following list will most likely overlap with things you’ve already covered):

  1. (As you said) Split into structure and encoding layers. The core spec should define the vocuablary, structure and semantics of messages and fields. Message, group and field types should be identified by name and version (and possibly namespace).

  2. The structure layer might need to be layered by it self. The top layer would be the application layer. The other possible layer I’m thinking of is the session layer, which is not necessary associated with a particular encoding. The current FIXT spec is mostly independent of the encoding layer (which incidentally is defined in the FIX 5.0 spec …), but there are some remainings like BodyLength and CheckSum.

  3. (follows from 1) Break out all encoding stuff from the core spec: FIXML, Tag/Value.

  4. Remove encoding artifacts from the structure specs. Examples of artifacts are: tag numbers (could be retained for convenience but should have a less central role), length fields for repeating groups and data fields, special handling of the occurence of the first field of a repeating group, BodyLength, CheckSum.

  5. Fixup name styles used in specs. Now there are at least these styles of type names: with upper case first letter, lower case first letter, “camel back”-names like MultipleStringValue, and names with a dash: month-year

  6. Publish a machine readable structure repository in XML that uses XML in a more natural way than the current repositories do (they happen to use the XML syntax, but the structure looks more like a relational database). The new repository should be encoding neutral at its core but should have support for annotations to be used for arbitrary purposes. One obvious candidate for inclusion as annotations would be the data needed for the tag/value encoding: tag numbers for fields and also tag numbers for the length fields of repeating groups and data fields.

/David

Hi David,

I completely agree. This is something that the GTC FIX 5.0 Usage
Subcommittee (http://www.fixprotocol.org/committees/fix5.0usage) is
currently addressing.

Our current proposal treats the messages, groups, and fields defined in
the FIX 5.0 specification as a data model for business content. Fields
that do not convey business content will be moved out of the FIX 5.0
specification and into the FIXT specification for the sole use of FIXT.

The following document outlines the current proposal -
http://www.fixprotocol.org/documents/3510/FIX5_Components_v0.2.doc (you
may need to be a member of the group to see this document – let me know
if you have trouble getting it).

I would welcome your involvement in this group to help sort out
these issues.

  • steven