How to treat 'imported' TermRefs such that they become convertable

[RieksJ]

When the HRGT generates a HRG from an MRGRef which specifies (a particular version of) some MRG, that may have been generated in the current scope, or imported from some external scope, it is very likely that the HRG entries that are generated will include TermRefs, and the idea is that such TermRefs should be resolvable from the MRG for which the HRG was created (even though this is may not be true in all cases).

• do we need a mechanism within the HRGT that can convert such TermRefs to something that a subsequent TRRT call knows what to do with?
• do we need to specify constraints that MRGs must satisfy so that any HRGs created from them will always be ok regarding any TermRefs that they may include?
• ....?

Let's think a bit about this before taking actions to resolve this

[RieksJ]

I can see various options:

1. have a mechanism that allows TRRT to shift current-scope dynamically (and back)
2. have the HRGT call the TRRT (with custom importer/converter) to act on the HRGlist after it has been generated
3. create a tool that allows actual insertion of predefined textfiles at particular locations; then, the HRGT can write a HRG-file that can be inserted, and the curators will then need to provide the actions that call the TRRT for such files to convert termrefs to other termrefs (changing the scope, for example), which then can be inserted at the right position and the TRRT can then be called as usual

[RieksJ]

The basic problem seems to be that if an MRG entry is imported from an external scope (be it as part of a completely imported MRG or as an MRG entry that was selected from an MRG imported from an external scope), their TermRefs are to be interpreted as they would have been in their originating scope. Problems this may pose include:

1. the termref interpreter used in the external scope differs from what is used in the current scope;
2. default values for named capturing groups in the termref may differ between the external scope and the current scope;
3. ...???

We need to find out if there are more such discrepancies, and then think about whether this is an issue to address, and if so, how to do that.

[RieksJ]

Analogous to #27, we might make maps of interpreters and converters (naming the interpreters and converters, as if we have additional 'predefined' ones). The idea could be that we might think of how to employ this, e.g., by stuffing them into the MRG, such that in other contexts, this can be used to interpret and convert termrefs found in MRG entries (e.g. by specifying 'defaults' for them in the MRG), or as values in glossaryTermRefInterpreter and glossaryTermRefConverter fields of MRG entries.

we must PROPERLY DEFINE if/how this might work

[RieksJ]

Let's do it as follows:

• [ ] The XX-tool must have a predefined converter (according to the TRRT converter profile), that creates a TermRef that is interpretable by the default TRRT interpreter.
• [ ] Every scope defines its (default) termref interpreter. If it does not, that defaults to the default termref interpreter [showtext](termType:term@scopetag:vsntag). Also, it has a field that specifies the converter that generates a termref according to this, its (default) termref interpreter. Failute to do so expects that this will be the (predefined) converter for the default termref.
• [ ] Every MRG will copy this termref interpreter in its header. When not specifed, it WILL make an entry in its header for teh default termref interpreter, so that field is always there.
• [ ] When the MRGT imports an MRG entry from an existing MRG, it will check EVERY field for termrefs according to the interpreter that is specified in the header of the existing MRG, and will convert it using the predefined converter (see first checkbox), where the value of the scopetag may be replaced by the value of the scopetag as is known in the current scope.
• [ ] The specifications need to be updated, i.e.:
  • [ ] files/SAF
  • [ ] files/MRG
  • [ ] specs/mrgt
  • [ ] texts about generation of provisional MRG entries

[Ca5e]

While working on the code regarding the conversion of termrefs included within mrg entries imported from an external scope, I came to realise that a good amount of work still has to be done in order to achieve the desirable result. The following observations are related to this, and give an update about the status of this issue.

• The current idea is that the MRGT performs a conversion of termrefs when it handles mrg entries from an external scope. As of right now, the MRGT does not have a converter that can perform this task (only the TRRT and HRGT do). I'm still not sure what most effective maintainable way would be to add this behaviour, but am working on it.
• Centralisation of the predefined mappings of converter templates, interpreter regexes, and macro mappings, seems to be the solution in order to not have to duplicates of the same default within multiple tools. For instance, when a MRG is created by thr MRGT and no interpreter is provided within the SAF, the default interpreter has to be retrieved (which is currently only stored within the interpreter of the TRRT).
• Instead of providing a converter along which we convert termrefs from external scopes, we can use the RegExT tool to derive the converter string from the interpreter regex. I've added a simple playground so the tool can easily be used.

[RieksJ]

A workaround could consist of the following:

• [ ] add a parameter to the TRRT, specifying the terminology (MRG) that it is to use to resolve TermRefs for the default scope. E.g., -tid <tid> (or --terminology <tid>), where <tid> is a terminology identifier. This may even be a good idea on its own...
• [ ] add a parameter to the HRGT, that, if present, resolves every TermRef in the HRG-entries it has created, using the terminolgy specified by <tid> as its default scope, similar to the point above. The idea is that the MRG associated with the <tid> would contain the default interpreter for the TermRefs used therein.