We are currently taking a mixed approach to field naming:
All the numeric fields are converted to more descriptive equivalents (e.g. 1 is converted to issuer in DgcCertContainer)
Every other fields is not renamed and we end up with things like: fn rather than something more descriptive like family_name.
I'd like to go for a descriptive approach, leaving to serde the responsability to rename the fields back to their original format in case we want to re-serialise the structs (for instance to JSON).
In the example above we are deserialising the field fn to family_name (better api for the user) but we tell serde to serialise it back to fn if we have to serialise the struct again (e.g. to JSON).
Since this will be a significant breaking change, I'd like to mark this for 0.1.0. But I suggest it's tackled as part of #6!
We are currently taking a mixed approach to field naming:
1
is converted toissuer
inDgcCertContainer
)fn
rather than something more descriptive likefamily_name
.I'd like to go for a descriptive approach, leaving to
serde
the responsability to rename the fields back to their original format in case we want to re-serialise the structs (for instance to JSON).As an example (suggested by @dodomorandi in #27):
In the example above we are deserialising the field
fn
tofamily_name
(better api for the user) but we tellserde
to serialise it back tofn
if we have to serialise the struct again (e.g. to JSON).Since this will be a significant breaking change, I'd like to mark this for
0.1.0
. But I suggest it's tackled as part of #6!