Change Request
Introduction
A Change Request (CR) is a proposal by an ECLASS user (=requestor) to change a part of the content of the ECLASS classification system. It can be a correction or even a deletion of something that is identified by the requestor as wrong, or an enhancement of something that is still missing. Generally, the ECLASS classification system will never be finished, as changes will always be necessary as long as markets are evolving. The number of Change Requests processed within a release varies according to the temporary requirements of the industry. The biggest release in regard to the number of submitted Change Requests was ECLASS 7.0 where more than 260,000 CR were processed. Different kinds of CR are valid in different kinds of releases.
All ECLASS Change Requests have to concur to the guidelines and rules for the maintenance of the ECLASS classification system that are described in this wiki. The front end for the submission of ECLASS CR is the ECLASS ContentDevelopmentPlatform. For internal use of bulk requests, an MS EXCEL© template approved by the ECLASS office can be used. Submitted CR are proposals for the modification of existing structural elements and their relations with each other, as well as additions of new structural elements and relations between new and/or existing structural elements. To ensure that ECLASS users have a high planning security, changes that might result in a necessary migration of one’s data, will be done along a plan, the release roadmap.
Requests for changes and/or enhancements being submitted to ECLASS are being checked for formal correctness by the ECLASS CRM first. A first plausibility check on the content is done, too (if possible, e.g. due to language restrictions). Depending on the content, the change request (CR) might be split first before being forwarded to the responsible ECLASS expert groups (EG) for the verification of the content. The editing process for CR is formalized in a standardized way according to international recommendations by e.g. the CEN.
Each CR that is submitted to ECLASS, has to contain at least the following information:
1. A new version of the changed area or the new content that is requested
2. All mandatory fields – depending on CR type and structural element
3. The reason for the change
4. Contact details in case of questions
Valid Change Requests per Release Type
The following table lists all types of Change Requests that are currently possible in an ECLASS Release. The list includes the information in which type of Release the change can occur. For more information of the different Release Types, please see The Release Process.
| Structural Element | Change Request Type | Valid in ServicePack | Valid in MinorRelease | Valid in MajorRelease |
|---|---|---|---|---|
| Classification Class | Change textual information | x | x | x |
| Classification Class | Create New | x | x | |
| Classification Class | Remove (only on 2nd and 3rd level) | x | ||
| Classification Class | Assign Property | x | x | |
| Classification Class | Withdraw Property | x | ||
| Classification Class | Assign Keyword | x | x | |
| Classification Class | Withdraw Keyword | x | x | |
| Classification Class | Move Class | x | ||
| Classification Class | Split Class | x | ||
| Classification Class | Join Class | x | ||
| Classification Class | Assign Application Class | x | x | |
| Classification Class | Withdraw Application Class | x | ||
| Application Class | Change textual information | x | x | x |
| Application Class | Create New | x | x | |
| Application Class | Remove | x | ||
| Application Class | Assign Aspect | x | x | |
| Application Class | Withdraw Aspect | x | ||
| Application Class | Assign Reference of Block | x | x | |
| Application Class | Withdraw Reference of Block | x | ||
| Application Class | Assign Property | x | x | |
| Application Class | Withdraw Property | x | ||
| Property | Change textual information | x | x | x |
| Property | Create New | x | x | |
| Property | Remove | x | ||
| Property | Replace | x | ||
| Property | Substitute | x | ||
| Property | Clone | x | x | |
| Property | Assign Synonym | x | x | |
| Property | Withdraw Synonym | x | x | |
| Property | Assign Unit | x | x | |
| Property | Assign Value list | x | x | |
| Property | Withdraw Value list | x | ||
| Property | Assign Property Condition | x | x | |
| Value List | Change textual information | x | x | x |
| Value List | Create New | x | x | |
| Value List | Remove | x | ||
| Value List | Assign Value | x | x | |
| Value List | Withdraw Value | x | x | |
| Value | Change textual information | x | x | x |
| Value | Create New | x | x | |
| Value | Remove | x | ||
| Value | Create CVA | x | x | |
| Keyword | Change textual information | x | x | x |
| Keyword | Create New | x | x | |
| Keyword | Remove | x | x | |
| Synonym | Change textual information | x | x | x |
| Synonym | Create New | x | x | |
| Synonym | Remove | x | x | |
| Aspect | Change textual information | x | x | x |
| Aspect | Create New | x | x | |
| Aspect | Remove | x | ||
| Aspect | Assign Reference of Block | x | x | |
| Aspect | Withdraw Reference of Block | x | ||
| Aspect | Assign Property | x | x | |
| Aspect | Withdraw Property | x | ||
| Block | Change textual information | x | x | x |
| Block | Create New | x | x | |
| Block | Remove | x | ||
| Block | Assign Reference of Block | x | x | |
| Block | Withdraw Reference of Block | x | ||
| Block | Assign Property | x | x | |
| Block | Withdraw Property | x | ||
| Unit | Change textual information | x | x | x |
| Unit | Create New | x | x | |
| Unit | Remove | x | ||
| Mapping Basic-Advanced | Create Mapping | tbd | tbd | |
| Mapping Basic-Advanced | Manage Mapping | tbd | tbd | |
| Templates | Manage Templates | tbd | tbd |
General rules for Change Requests
The requestor has to affirm that established norms, standards and guidelines were considered when creating the CR. If the CR was submitted by an ECLASS EG, they have to confirm that the submitted CR was consolidated with the whole group. CR can only be submitted, if the following preconditions are valid:
- All mandatory fields are filled in English (if possible, also in German and other languages)
- They meet all formal requirements (ContentDevelopmentPlatform, Import Template)
- They meet the guidelines on spelling, syntax, field formats, units, definitions etc.
- The CR is in conformity to the data model
- In case a CR was submitted for a MinorRelease its content has to be checked if it contains only compatible changes
- Certain special characters are not allowed in text fields. Special characters are characters that are neither a letter, nor a number and are used as control characters (according to ISO 2382-4). Some special characters cannot be handled by some IT applications and are therefore no allowed (see figure below).
- No line break is allowed
- No structural element is deleted. Structural elements can be withdrawn, assignments can be withdrawn. But all structural elements will stay part of the ECLASS dictionary and simply be marked as deprecated, i.e. they are kept in the database. An identifier cannot be used again (unlike a class CodedName that can be used again after some releases).
For an overview of all formal rules, please see the following section about naming rules and Figure 1: Overview of characters, below.
Naming rules
**In the VA PreferredName only in terms of greater than, less than
For an overview of all formal rules please see Figure 1: Overview of characters below.
Apart from that the following general naming rules apply:
- Generally, names shall be written as in common language, e.g. Property BAB050 "static load number" (AND NOT: "load number, static")
- Always use the singular form, exception: plural words as e.g. glasses, scissors, trousers etc.
- No trademarks, company or brand names are allowed anywhere in ECLASS
- No abbreviations allowed in class names
- Round brackets ( ): Additions to a PreferredName that are not part of the name itself, can be added behind the name in round brackets. It can be references, additional information on the application area or a restriction
- Example 1: all additional names in descriptive codes of parts (parts), accessories (accessories) and (unspecified)
- Example 2: to refer to a norm: Property AAL060 "cross gearing (acc. DIN MX) present"
- Example 3: to refer to an application area: (lab), (medical), (marketing)
- Unit reference: Is only allowed in the PreferredName of properties (same rules for ValueLists) and values and has to be done with the help of round brackets
- Example 1: unit reference in property AAF975 "max. rated voltage (at AC 50 Hz)"
Certain other naming rules apply for the creation of new structural elements. These rules are listed in every single section of a certain structural element.
Please see the sections of the structural elements for further reading:
- Classification Class (same applies for Application Class, Aspect and Block)
- Keyword
- Property (same applies for Value List)
- Value
For an overview of all formal rules, please see the figure below:
Figure 1: Overview of characters
All other rules for Change Requests are to be found on the relevant pages of each structural element, see Using the Content Development Platform
Advanced CR Import
The updated sample file for Advanced CR Import contains example CRs that are relevant for Advanced CR Import: Reactivate Property, Reactivate Value, Move Classification Class, Assign/Unassign Aspect etc.
Change Request Process - Major Minor Workflow
The new Change Request workflow consists of following steps:
Step 1: Submit CR
Change Requests are submitted under menu My Change Requests.
Step 2: Propose CR for Accept
Change Requests can be proposed for accept under menu entry Office – Check Requests.
Step 3: Add CR to WP
New Work Package is created for packetizing the Change Requests.
Step 4: Start Process "Major-Minor Release"
Minor-Major workflow can be started under menu entry Office – Work Package List.
Step 5: Add the Responsible user for new WP
After responsible user for new Work Package is selected, process is successfully started.
Step 6: Work on task “Check if workpackage is in scope of expert group”.
1. Select menu entry User – My Tasks:
2. Click task description, in order to view its details:
3. Select desired Expert Group. 4. User may either choose to Rework WP or Forward WP to selected Expert Group. 5. Select option Forward WP to Expert Group, click button Commit, in order to continue Major-Minor Process => Task of type “Work on work package” is created.
Step 7: Work on task “Work on workpackage”.
1. Select Task details and View subject. 2. Create CP for CR.
3. As soon as CP is created, return to Task details, via Back button. 4. Select radio button "Submit WP for verification" and press Commit button => new task is of type “Workpackage technical correctness” is created
Step 8: Work on task “Workpackage technical correctness”
1. Select task. 2. Click option “Forward workpackage - quality check”. 3. Press Commit button => new Task of type “Workpackage quality check” is created.
Step 9: Work on task of type “Workpackage quality check”
1. Select task and click option View subject. 2. Check the box of existing CPs and button Confirm all CPs is activated. Same, for CRs. 3. Confirm all CPs and return to task view via Back button. 4. Mark option Approve WP and click button Commit.
Outcome:
- WP will no longer be displayed in task list.
- WP may be seen under Office / WP list (for WPs already sent), in status RELEASE.
- CP in status Accepted may be found under Office Chair, ready to be released.