What are the required link fields in a chain header?

Constantine

Let's suggest I am building chains with mostly lower level API so I cannot rely on any framework smartness. Thus I need to know what are at least the mandatory chain header fields to build proper chains. I tried to see the available documentations (like "Simple Chain objects for EMA Part 1, Part 2") and everybody says that the required fields are REF_COUNT, link fields and next fields. That's find but unfortunately I cannot find what is the standard/common practice for the amount of the link fields

Should all 14 links (does not matter LINK_N, LONGLINKN or BR_LINKN) be in presence (some on them probably empty)? At least one of them (probably empty)? No link fields (if REF_COUNT is 0)?

What the standard/common practice say about this to build proper chains accepted by all potential processors? In fact, I faced an application that considered zero amount of link fields as an error although the REF_COUNT was set to zero as well. That's why the question is asked.

moragodkrit.chumsri_1

@Constantine

Let me share my experience when dealing with Chain RIC.

First of all, my application just checks if the fields list contains REF_COUNT with 14 links fields and it must contain Next and Prev links fields. Then I will mark the RIC as a valid chain because it contains a valid chain template.

In theory, the way to process links fields should be the same as described in the pages you mentioned. But there is some case that the feed does not send the data according to the spec.

In the past, I found the case that some chain providers might automatically pass a list of string which is a value of 14 link fields. But it looks like, they do not verify if some fields contain an empty string or not. Some RIC just removed so they set to empty to preserve the number of Chain Records. Also, you might see the case that REF_COUNT is 14 but some fields in the links are empty. Or sometimes REF_COUNT is 10 but they also use LINK_12,13 and 14 and set the value of some link field to empty instead. Anyway, the number of non-empty link fields still matches with the REF_COUNT. Also, there is some case that REF_COUNT is 0 and all link fields are empty but when subscribing to the next Chain Record, it still contains a valid Chain REF_COUNT and Links. It looks like they use this approach to preserve the number of Chain Records and will have a plan to update it later.

With the following exception and issue that may occur for some Chain, therefore, my app will get RIC from 14 link fields by not checking the value of REF_COUNT. I assume that chain RICs presented in link fields should be valid RIC though the number does not match with REF_COUNT. Anyway, I have to logs unusual case to app logs and then reports these case to the content support team to get clarity from the team who take care of the Chain.

API or client app cannot change or populate content so this is the only way we can do to handle links field.