Hi,
The description in the Filing History call returns in the form
“a-string-of-words-separated-by-hyphens”
Is there any plan to have a different description returned, similar to on the beta site?
Hi Hywel.
What you’re missing is access to the enumeration repository, which will initially be made available through github. This will give you the necessary enum to display string lookups. We are also looking at providing an API endpoint to access the enumeration lists, which will allow mobile apps and other rolled-out applications to avoid building in the lookups and to keep in step with enumeration value changes.
As you will have seen, through customer feedback we’re changing and cleaning up some of the resources, such as the search API, and this affects the enumeration values. We’re currently doing the work required to release the enumerations.
Best.
Has any progress been made on this? For a service who’s PRIMARY purpose is to provide filing history, it seems a bit remiss to not actually give a valid description of each item in the filing history
We have made the github repository available with the descriptions and can be found at the following link:
Are there any plans to provide a simple plain text description similar to what we get with the XML gateway with the response? The amount of post-processing now required to get what used to come with the response feels like a bit of a step backwards.
Hi
Can you please explain the rational behind providing a lookup value, with enumerations and possibly an API, rather than just populating the description with the actual value. No other part of CHS works this way.
The way you have gone will require ANY user to have to do a lot of post processing on the data, which is less than ideal.
Given that your BETA site populates the “full” description, I assume you already have a module to create this description, could you either prepopulate a “full” description or make the module accessible via an API?
Cheers
Hywel
Hi it would appear that your GitHub repository stores a list of strings, that need parameters added.
e.g.
‘capital-cancellation-shares’ : “*Cancellation of shares.* Statement of capital on {date}”
Do you have a mapping document between the parameters needed and the API values returned?
Since there are numerous dates returned in many of the calls that would use this (and other) examples, how is the end user to know which one to use?
Again I ask, why not provide the formatted description that you use in your BETA site?
1 Like
If you loop through the items in description_values you can use these to fill in the blanks. Which requires more post processing on our part and is not ideal.
It also creates a whole other problem which I’ll make a seperate thread for.
For items where the description is “legacy” then the actual fully rendered description string is in descitpion_values.
Thanks Ash, hadn’t noticed the “description_values” field, What a fantastically elegant solution… 
And then you need to recursively check associated filing(s) and resolutions and they have their own descriptions that need to be looked up and description_values that need to be replaced!
It gets more confusing when you look at something like a “statement-of-capital” as this has a single value {date} that needs to be substituted as well a description_value “capital” which is actually a tuple of two other values with no indication of where it should go in the description. It also has an “original description” value.
Question on this topic: why the double asterisks in the enumerated descriptions?
It’s standard markdown language, so double asterisks is to identify bold. Not sure how useful this is though to API users.
Thanks
Mark.