OCDTv3 and COMET parameter sheet are incompatible.

[JVennekens]

Prerequisites

• [X] I have written a descriptive issue title
• [X] I have verified that I am running the latest version of the COMET-IME
• [X] I have searched open and closed issues to ensure it has not already been reported

Description

The COMET and OCDTv3 parameter sheets are different making previous generated formulas and links incompatible.

1. the actual value field of the parameters and identifier has a different name. OCDT; Element_definition_shortname\Parameter_type shortname\State\option eg: BEE\Shape\ COMET: Element_definition_shortname.Parameter_type shortname(\State\option) eg: BEE.shape
2. It would be useful if COMET would also automatically make the parameter sheet a table so filtering would be easier.
3. Having an extra column to specify the State and a column for the option will make it easier to filter if needed.

The above differences should be fixed in COMET, either by modifying the COMET parameter sheet or the option to select and OCDT or COMET parameter sheet generation. CDP4 parameter sheet.xlsx OCDT parameter sheet.xlsx

Steps to Reproduce

Logs

• [ ] There are no logs regarding the issue
• [ ] I have attached a log file or included the relevant section in this issue

System Configuration

• COMET version:
  • [ ] COMET-IME:
  • [ ] Other:
• Web Services:
  • [ ] CDP4/COMET Web Services version:
  • [ ] OCDT WSP version:
• Environment (Operating system, version and so on):
  • [ ] Microsoft Excel (32/64 bit):
  • [ ] Windows OS (32/64 bit):
  • [ ] Additional information:

[alexatstariongroup]

@samatrhea can you please review this issue and let us know what you would like to do with regards to the 3 points above? Should a user have an option to choose COMET/OCDT sheets or should we unify?

@cozminvelciu investigate modelcode correctness and post here.

[cozminvelciu]

@alexatrhea I've done a thorough investigation on how the path was displayed and implemented in ConCORDE here. The summary is that it was always implemented as using backslashes as separators, and not dots.

W.r.t. the 10-25 TM, there seems to be no mention of paths for parameter (or subscription) value sets, as the path is implemented as an extension there, but there is a description for the NestedParameter.Path property:

derived unique short name path to this NestedParameter

Note: The path string consists of the following backslash separated parts: (1) path to the nestedElement, (2) path to the associatedParameter, (3) path for the actualState or empty string if that is null, (4) shortName of the container Option. Any nested parts of the path name are dot separated.

Based on the above description, it seems like the correct way to generate the path according to 10-25 would be to have ED\Par\State\Option (using backslashes), and use dots only for nested parts (e.g. parameter components) - which is what OCDT is doing.

[alexatstariongroup]

@samatrhea your final word on the issue with regards to either correct or make it optional?

[alexatstariongroup]

From OCDT documentation on Parameter sheet:

<ElementDefinition.ShortName>[.<ElementUsage.Shortname>]\<ParameterType.Shortname>[.<ParameterType.Component.ShortName>]\[<ActualFiniteState.ShortName>]\[<Option.ShortName>]

so indeed there is a bug.

@lxatrhea I propose we split this off from this task and fix it in a bug task and leave the flat table with filtering columns as a new feature as there we would for sure need to split how Parametersheets are generated now to the 'OCDT' way.

[lxatstariongroup]

@alexatrhea We need to be careful with backwards compatibility in reports. Writing back values to reports is based on these model codes and easier support for different Options is implemented "under the hood".

[lxatstariongroup]

@alexatrhea We need to be careful with backwards compatibility in reports. Writing back values to reports is based on these model codes and easier support for different Options is implemented "under the hood".

@alexatrhea Good news: The Model Codes used in reports are already constructed in the same way as the cell names in the OCDT parameter sheet. No problems or backwards compatibility issues there.