Morendil
commented
5 years ago Thanks @magemax for the feedback! I think the legislation explorer is correct, but other parts of the product do need fixing. More (much more) detail below.
in the trace of an attached YAML test, it's a numeric value that appears (for example 5 for statut_marital="pacsé" ).
Numeric values are hard to interpret, they force you to look them up in the documentation frequently, or you have to memorize mappings of integers to meanings (and this could all change if you add new values).
The OpenFisca team put in a lot of effort into supporting "enumerated" values instead. Enumerated values are those which come from a finite set of possible choices (whereas integer types are unrestricted).
I'm pretty sure that the current behaviour of Legislation Explorer is correct and intended. The mistake is rather in the trace, which would be more helpful by showing the symbolic value pacse. It is often the case that less effort is put into debugging tools, because we assume that they'll be used by developers, and we think that they have magical guessing powers that allow them to know that 5 means "Pacsé" without having to ask. (Just kidding, of course. Developers acquire knowledge the same way everyone does.)
If you're OK with that, I recommend closing this issue and instead opening one on Core, suggesting that the trace would have more value if it showed symbolic values rather than numeric.
For example : https://fr.openfisca.org/legislation/statut_marital
We expected to see in the documentation the index corresponding to each value type, and the value described as an integer rather than a string. The fact that it's an enum could also be specified in the documentation.
Actually, the value is presented as a string but in the trace of an attached
YAML test, it's a numeric value that appears (for example 5 for statut_marital="pacsé" ).