Closed dirk-qualisys closed 4 years ago
This affects only UnitIdEnum, which is used in OneUnitValue and UnitValue. OneUnitValue has just two occurrences in the EU specific fields, but UnitValue has many occurrences.
Besides UnitIdEnum as an attribute(!), both use another attribute for a reference to a Norwegian Website with unit sets which is no longer maintained, plus a string field for Units. Because of references to "eye" and "animal", this needs to be a phrase.
This basically goes back to issue #26, where the original decision was to replace them with the next release as intended here, and then this was revoked because a mapping as necessary anyway and the change was not worth the effort in version 4. With the scope (and audience) extension and resulting structural changes, the advantages of a readable and consistent specification do outweigh the disadvantage of a changed mapping for existing implementations.
I took the opportunity to rename type OneValue to ExactValue, and its field Value to ExactValue so that it is consistent with ExactValue in type Value.
SDScom is meant to be independent from a specific phrase catalogue. This includes EuPhraC, although both are developed together. So any enumeration of EuPhraC phrase IDs is an implementations hurdle for users of other phrase catalogues, because they need to implement a mapping. This affects UnitIdEnum.
Issue #201 accompanies translatable values with a phrase ID so that phrases can be used although the content is readable in the enumeration itself. This concept should be used for the replacement of such pphrase ID based enums.