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
morphandfixto 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@inand@out. Don't know if this@would be ok forfixalso @fsteeg ? Do we need any more annotations besides@inand@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 & fixthemselves).