Change Request

Jump to: navigation, search


[edit] Introduction

A change request (CR) is a proposal by an eCl@ss user (=requestor) to change a part of the content of the eCl@ss 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 eCl@ss 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 eCl@ss 7.0 where more than 260.000 CR were processed. Different kinds of CR are valid in different kinds of releases.

All eCl@ss change requests have to concur to the guidelines and rules for the maintenance of the eCl@ss classification system that are described in this wiki. The front end for the submission of eCl@ss CR is the eCl@ss ContentDevelopmentPlatform. For internal use of bulk requests an MS EXCEL© template approved by the eCl@ss 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 eCl@ss 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 eCl@ss are being checked for formal correctness by the eCl@ss 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 eCl@ss 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 eCl@ss, 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

[edit] Valid Change Requests per Release Type

The following table lists all types of change requests that are currently possible in an eCl@ss 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 Keyword x x
Aspect Withdraw Keyword x 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 Keyword x x
Block Withdraw Keyword x 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

[edit] 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 eCl@ss EG, they have to confirm that the submitted CR was consolidated with the whole group. CR can only be forwarded to the Center for Quality Control (CQC), if the following preconditions are valid:

1. All mandatory fields are filled in English (if possible, also in German and other languages)

2. They meet all formal requirements (ContentDevelopmentPlatform, Import Template)

3. They meet the guidelines on spelling, syntax, field formats, units, definitions etc.

4. The CR is in conformity to the data model

5. In case a CR was submitted for a MinorRelease its content has to be checked if it contains only compatible changes

6. 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).

7. No line break is allowed

8. No structural element is deleted. Structural elements can be withdrawn, assignments can be withdrawn. But all structural elements will stay part of the eCl@ss 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.

[edit] Naming rules

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 eCl@ss
  • 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 elemements for further reading:

For an overview of all formal rules, please see Figure 1: Overview of characters:

Figure 1: Overview of characters


*Exception: written as a whole to indicate a condition a unit is allowed in a property’s definition

**In the VA PreferredName only in terms of greater than, less than

All other rules for change requests are to be found on the relevant pages of each structural element, see Category:Using the Content Development Platform

[edit] 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.

This can by found under: Advanced CR Import - Sample File

[edit] 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.

Figure 1: Start Major Minor Workflow'


Step 5: Add the Responsible user for new WP

After responsible user for new Work Package is selected, process is successfully started.

Figure 2: Process started successfully


Step 6: Work on task “Check if workpackage is in scope of expert group”.

1. Select menu entry User – My Tasks:

Figure 3: Menu entry My Tasks


2. Click task description, in order to view its details:

Figure 4: Task 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.

Figure 5: 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

Figure 6: Submit work package for verification


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.

Figure 7: Forward WP to Quality Check


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.

Figure 8: Approve Work Package



• 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.

[edit] Related information

[edit] References

- CEN (Comité Européen de Normalisation, European Committee for Standardization), Workshop ePDC on Global Multilingual Product Description and Classification for eCommerce and eBusiness. See CWA 15295:2005, p. 35ff.



Personal tools