Unify concept naming convention from *_identifier to identifierNAME

base_classes/NXatom.nxdl.xml

@@ -38,7 +38,7 @@
             the element or (molecular) ion like such as Al +++ or 12C +.
         </doc>
     </field>
-    <field name="chemical_identifier" type="NX_CHAR">
+    <field name="identifier_chemical" type="NX_CHAR">
         <enumeration>
             <item value="inchi"/>
         </enumeration>

base_classes/NXem_ebsd.nxdl.xml

@@ -509,22 +509,22 @@ enumeration: [undefined, Bruker, JEOL, FEI, Oxford]-->
                  In another example users may have skipped some scan points (not indexed
                  them at all) or used differing numbers of phases for different scan points.
 
-                 The cumulated of this array decodes how phase_identifier and phase_matching
+                 The cumulated of this array decodes how identifier_phase and matching_phase
                  arrays have to be interpreted. In the simplest case (one pattern per scan
                  point, and all scan points indexed using that same single phase model),
-                 phase_identifier has as many entries as scan points
-                 and phase_matching has also as many entries as scan points.
+                 identifier_phase has as many entries as scan points
+                 and matching_phase has also as many entries as scan points.
             </doc>
             <dimensions rank="1">
                 <dim index="1" value="n_sc"/>
             </dimensions>
         </field>
-        <field name="phase_identifier" type="NX_INT" units="NX_UNITLESS">
+        <field name="identifier_phase" type="NX_INT" units="NX_UNITLESS">
             <doc>
-                 The array phases_per_scan_point details how the phase_identifier
-                 and the phase_matching arrays have to be interpreted.
+                 The array phases_per_scan_point details how the identifier_phase
+                 and the matching_phase arrays have to be interpreted.
 
-                 For the example with a single phase phase_identifier has trivial
+                 For the example with a single phase identifier_phase has trivial
                  values either 0 (no solution) or 1 (solution matching
                  sufficiently significant with the model for phase 1).
 
@@ -535,11 +535,11 @@ enumeration: [undefined, Bruker, JEOL, FEI, Oxford]-->
                  or false or inaccurate phase models e.g. (ferrite, austenite).
                  Having such field is especially relevant for recent machine learning
                  or dictionary-based indexing methods because in combination with
-                 phase_matching these fields communicate the results in a
+                 matching_phase these fields communicate the results in a
                  model-agnostic way.
 
-                 Depending on the phases_per_scan_point value phase_identifier and
-                 phase_matching arrays represent a collection of concatenated tuples,
+                 Depending on the phases_per_scan_point value identifier_phase and
+                 matching_phase arrays represent a collection of concatenated tuples,
                  which are organized in sequence: The solutions for the 0-th scan point,
                  the 1-th scan point, the n_sc - 1 th scan point and omitting tuples
                  for those scan points with no phases according to phases_per_scan_point.
@@ -548,18 +548,18 @@ enumeration: [undefined, Bruker, JEOL, FEI, Oxford]-->
                 <dim index="1" value="n_solutions"/>
             </dimensions>
         </field>
-        <field name="phase_matching" type="NX_INT" units="NX_UNITLESS">
+        <field name="matching_phase" type="NX_INT" units="NX_UNITLESS">
             <doc>
                  One-dimensional array, pattern by pattern labelling the solutions found.
                  The array phases_per_scan_point has to be specified because it details
-                 how the phase_identifier and the phase_matching arrays are interpreted.
-                 See documentation of phase_identifier for further details.
+                 how the identifier_phase and the matching_phase arrays are interpreted.
+                 See documentation of identifier_phase for further details.
             </doc>
             <dimensions rank="1">
                 <dim index="1" value="n_solutions"/>
             </dimensions>
         </field>
-        <field name="phase_matching_descriptor" type="NX_CHAR">
+        <field name="matching_phase_descriptor" type="NX_CHAR">
             <doc>
                  Phase_matching is a descriptor for how well the solution matches or not.
                  Examples can be confidence_index, mean_angular_deviation, or other.

base_classes/NXevent_data_em.nxdl.xml

@@ -116,12 +116,12 @@
              when the snapshot time interval ended.
         </doc>
     </field>
-    <field name="event_identifier" type="NX_INT" units="NX_UNITLESS">
+    <field name="Identifier_event" type="NX_INT" units="NX_UNITLESS">
         <doc>
              Identifier of a specific state and setting of the microscope.
         </doc>
     </field>
-    <field name="event_type" type="NX_CHAR">
+    <field name="type" type="NX_CHAR">
         <doc>
              Which specific event/measurement type. Examples are:
 

base_classes/NXibeam_column.nxdl.xml

@@ -72,8 +72,8 @@
         </field>
         <field name="description" type="NX_CHAR">
             <doc>
-                 Free-text field to provide additional details if no (globally) persistent unique identifier
-                 can be provided via identifierNAME of the NXsource group.
+                 Free-text field to provide additional details if no (globally) unique persistent
+                 identifier can be provided via identifierNAME of the NXsource group.
             </doc>
         </field>
         <group name="probe" type="NXatom">

base_classes/NXphase.nxdl.xml

@@ -35,7 +35,7 @@
              null-model no sufficiently significant confirmation. In other words,
              the phase_name is n/a aka notIndexed.
 
-             The phase identifier value has to match with the integer postfix of the
+             The identifier_phase value has to match with the integer postfix of the
              group name which represents that instance in a NeXus/HDF5 file, i.e.
              if two phases were used e.g. 0 and 1, two instances of :ref:`NXphase`
              named phase0 and phase1 should be stored in that HDF5 file.
@@ -45,7 +45,7 @@
         <doc>
              Given name as an alias for identifying this phase.
 
-             If the phase_identifier is 0 and one would like to used
+             If the identifier_phase is 0 and one would like to used
              the field name the value should be n/a or notIndexed.
         </doc>
     </field>