To have a quick overview of what fields are transformed to what:
If we could agree on how to annotate comments in morph and fix to document the transformation (like in @in: field A @out: field B) we could automatically excerpt an overview of transformed fields, like:
We could do this in morph(i.e. XML) as comments - I think this would be the most simple approach. We could write a little program that would extract the information and create e.g. an CSV (pipe-separated, see above).
Comments could be prefixed with the @ (like for java annotations) and stick to @in and @out. Don't know if this @ would be ok for fix also @fsteeg ?
Do we need any more annotations besides @in and @out @TobiasNx ? (I think it would make sense to stick to the most basic description, i.e. not defining possible complex dependencies (which could us easily end on introducing a meta-level as complex as the morph & fix themselves).
This came up by @TobiasNx :
To have a quick overview of what fields are transformed to what:
If we could agree on how to annotate comments in
morph
andfix
to document the transformation (like in@in: field A @out: field B
) we could automatically excerpt an overview of transformed fields, like:(see how it is commented atm https://github.com/hbz/lobid-resources/blob/a6f8aa992ddaa91b83f5541e61d285dc36524d4a/src/main/resources/alma/common/subjects.xml#L4 )
We could do this in
morph
(i.e. XML) as comments - I think this would be the most simple approach. We could write a little program that would extract the information and create e.g. anCSV
(pipe-separated, see above). Comments could be prefixed with the@
(like for java annotations) and stick to@in
and@out
. Don't know if this@
would be ok forfix
also @fsteeg ? Do we need any more annotations besides@in
and@out
@TobiasNx ? (I think it would make sense to stick to the most basic description, i.e. not defining possible complex dependencies (which could us easily end on introducing a meta-level as complex as themorph & fix
themselves).