Example of lowerCamelCase
Parameter Input
Name | Description | Cardinality | Value Type |
parameterDataType | The datatype of the parameter input | 0..1 | Controlled Vocabulary |
parameterRole | Used to convey the Role of this parameter. For example: Weight, UpperThreshold, AgreementLevel
| 0..* | String |
parameterValue | The content of the parameter | 1..1 | String |
Example of mixed naming for attributes
Process Control
Name | Description | Cardinality | Value Type |
startEvent | The event which triggered the control.
| 0..1 | String |
Status | Success or error, typically using a coded value.
| 0..1 | String |
Example of uppercase
Process Output Specification
Name | Description | Cardinality | Value Type |
Type | This denotes the type of object which can be used as an input. | 1..* | String |
Is now the most advantageous time to clean up the mixed naming conventions for attributes i.e. before there is a widespread local implementation of the current ones?
If it is, then I would recommend the use of lowerCamelCase.
This would need to be implemented consistently in the GSIM Specification, Clickable GSIM and the EA fil. As a minimum, it could be implemented consistently in the Enterprise Architect file that is used further by modellers, by LIM and by CSPA
If it is not desirable to clean this up in the next version of GSIM, if there already is a widespread local implementation of the GSIM v1.1 attributes, then it would at least be helpful to recommend a naming convention (e.g. lowerCamelCase) for names of attributes in Annex D: Extending the model. Perhaps in Box 1 Metamodel Template.
1 Comment
user-8e470
Meeting 17 October: the issue raised was about inconsistency of attributes naming convention within the document (e.g. upper case “Status”, lower camel case “startEvent”). The Team made comments that the convention may depend on the target audience (e.g. IT staff, business staff) and agreed to use lower camel case and try to ensure that the convention is consistently applied in all GSIM documents.