Tag text format clarification

[mic...@theandre.net]

 

Can you make the assumption that all fields in the Tagged text format comes in schema order (JSON and XML would be free order by definition) or is it free order since it tags. Free order makes it a bit more inconvenient to parse.

 

In general how relaxed should you be with decoding:

1. Field that doesnt exist in the schema? Silently discard/warn/err?
2. Mandatory field not in text? Initialize to default value silently/warn/err?
3. Extraneous whitspaces in field names or primitive values?

 

I guess you could have a strict and a relaxed mode with different behaviours?

 

/Michel

 

[Anders Furuhed]

Excellent questions.

Our idea with the tag format is that it should be human friendly, including allowing you to compose a message by hand or using UNIX filters ( http://en.wikipedia.org/wiki/Filter_(Unix)), at the potential expense of parsing overhead. Unlike FIX Tag/Value, Blink Tag is not an all purpose format. As an implementor, this means you should not spend too much time optimizing the parser. We may have missed out on workflows where there is a need for a higher performant tagged text format, so please challenge our idea of what the format is for. On the other hand, the techniques used in a highly optimized FIX tag parser dealing with free order could be reapplied here.

David will have to answer in more detail, but I would reason that:

1. this is an error, but you are going to want to be able to discard extraneous data. To make the parsing task clean and to avoid having to introduce a relaxed mode like you suggest, the question of discarding extraneous fields could potentially be moved to the schema level. If you want to accept the data, you would then have to add the field as being optional in the schema and then decide on the application level what to do with this data.
2. this is an error or we would have to define default values in Blink, making the distinction between mandatory and optional fuzzy and not making every word tell. There is a better solution - if you really want to accept missing data, let that view be reflected by your schema.

3. I personally don't think this should be relaxed, despite Postel's law, as explained in the second part of http://en.wikipedia.org/wiki/Robustness_principle.

[david.rosenborg]

Good questions!

The order of the fields is insignificant in the Tag format. As Anders said in his reply, this is because we think it makes the format easier to use in general, even if parsing becomes a little less efficient.

We'll revise the spec to be more specific on these (and other) constraints. The approach will be consistent with the core specification where we basically put the stricter constraints on the encoder side but allow some flexibility to the decoder side. The 1-3 are all format errors, but at least 1 and 2 could be silently ignored by a particular decoder implementation. As you suggest, decoders could be used in a strict or relaxed mode, but this would still be an implementation detail not explicitly covered by the specification.

/David

On Friday, June 7, 2013 7:19:28 PM UTC+2, michel wrote: