Text variant annotation for model enumerations

[mttrbrts]

To support textual variants of the same enumeration element in a model, the model definition should allow annotations that enumerate text alternatives.

The annotation could also be used to capture language-specific variants of a model element.

This would clean up model enumerations so that they only need to define a single element per semantic element. Logic that operates on enumerations (for example match statements in Ergo) would then also not need to match multiple values

Where an annotation is not provided, the String value of the element would be used.

For example:

enum TemporalUnit {
  @alternativeText('day','days','jour','jours')
  o DAY
  //...
}

We could even consider something like a .language file to externalize language definitions, e.g.

enum TemporalUnit {
  @languageKey('DAY')
  o DAY
  //...
}

and in model.en.language

{
  "DAY": ["day", "days"]
}

• [ ] Agree on annotation keyword (alternative, alternativeText, verbalization, localization, textOptions etc..)
• [ ] Research existing ways to describe locale variants, e.g. Message Resource Property files in Java, Unicode CLDR etc.

[dselman]

My inclination is:

enum TemporalUnit {
  @localization_en( 'day', 'days')
  @localization_fr( 'jour', 'jours')
  o DAY
  //...
}

With the second key (plural) optional.

Note that in its current state Composer doesn't support multiple decorators with the same name on the same element.

Also, note that while an external localization file would be very nice for translation purposes it would be tricky to make it work with models that are loaded from URLs.

[jeromesimeon]

Should this issue moved to https://github.com/hyperledger/composer-concerto ?

[mttrbrts]

Yes, it should ...

[jeromesimeon]

Moved to https://github.com/hyperledger/composer-concerto/issues/26