Update serializers to include new Locality data

[stefanomunarini]

After adding new models (Locality, LocalityStack and BibItemLocality) (see https://github.com/relaton/relaton-py/issues/18) to accommodate more DOI data, we want to include them when serialising a BibliographiItem.

[strogonoff]

@stefanomunarini, so doi2ietf (doilit) used to serialize this into <seriesInfo>—but it suddenly turned out to be wrong (violates XML specification). I stated the task as “reimplement the same handling as in doi2ietf/doilit”, so you have done what was requested—the mistake was at planning stage.

Apparently, we are supposed to use <refcontent>, based on:

• Jean’s comment https://github.com/ietf-ribose/bibxml-service/issues/228#issuecomment-1177699864
• The spec on <refcontent>

(cc @ronaldtse)

[strogonoff]

Note that <refcontent> data model is apparently plain text, so in the serializer we might need to format the entire locality hierarchy as one human-readable string.

It’s up to you how to attack this, but some considerations:

• It’s probably worth encapsulating it in a separate, testable function that takes locality info and outputs a string (of course, if warranted, the logic can also be split further into smaller functions).
• This function doesn’t have to cover all possible locality data from the start. We can increase coverage as we go, using existing samples as minimum baseline.
• If we can write this nicely without extra requirements, that’d be ideal.
  • However, if this is a problem (f-strings don’t have conditionals, after all…), to prevent this logic from becoming a mess it may be worth adding a lightweight templating library to package requirements. I don’t really know a good one (Jinja2 seems overkill?), so let me know if you want to do this.