missing parent codelist names

[gabrieledall]

Why have some parent codelist definitions been removed in fields.json Version 1.3.x - especially those in BT-10-Procedure-Buyer and BT-610-Procedure-Buyer. Searching for these lists in the codelist-folder, I still find codelists following the parent/child schema for them:

main-activity.gc
main-activity_autority-activity.gc
main-activity_entity-activity.gc

First, I thought, this principle has been given up a a general rule, but later I saw that other codelists are still defined as child of o bigger parent codelist. Has some rule change taken place or is it a bug?

Regards
Gabriele

[YvesJo]

Hi,
I will illustrate with the provided example. BT-10 and BT-610 are two Business Terms that only use subsets of the main-activity codelist, the two subsets differ. There is no Business Term that my use the whole list main-activity.
Until recently the parent list was still referred for some fields and this had to be fixed by pointing to the subset instead. When the listName attribute has to be specified and differs from the list used for element content validation, the parent codelist name is available.

[rousso]

Hi @gabrieledall,

Indeed we removed the parentId from some codeList constraints in fields.json. It was wrong that we had placed them there in the first place.

The information provided in fields.json is not about codelists. It is about fields.
The information about codelists is provided in /codelist/codelist.json. This is the file where you should lookup the proper parent of a tailored codelist.

The codelist information inside fields.json is only about the usage of a specific codelist by a specific field.
Fields of type code, need to have a @listName attribute in their XML representation. The @listName attribute should be set to the codeList.parentId if it is present in fields.json for the codeList constraint of the specific field; otherwise, @listName shoudl be se to coddeList.id. That is why we removed the ones that should not be used in @listName from fields.json.

In all honesty our choice of name for the codeList.parentId property in fields.json is unfortunate. We should have instead added a listName property indicating the correct value to avoid confusion. Mea culpa.

I hope this helps,
Yannis