remove installation manual for cnxvalidate

Author: lukaspie

docs/how-tos/pynxtools/validate-nexus-files-other-tools.md

@@ -38,86 +38,11 @@ In case you are interested in testing these tools, we encourage you to follow th
 ??? info "A note on operating systems"
     Note that installation on Windows can be tricky because cmake can sometimes not find the libxml2 library. Though, if you solve this, this may work on Windows. Therefore, we recommend to use Linux.
 
-The tool `cnxvalidate` is written in C and has to be built from source (e.g., by using `cmake`).
-
-#### Install `cmake`, `HDF5` & `xml2` libraries
-
-Install all dependencies required to install `cnxvalidate` via `cmake`:
-
-```console
-sudo apt-get update
-sudo apt-get install git
-sudo apt-get install build-essential
-sudo add-apt-repository universe
-sudo apt-get install libhdf5-serial-dev
-sudo apt-get -y install pkg-config     
-sudo apt upgrade -y
-sudo apt-get -y install cmake
-sudo apt-get install libxml2-dev
-```
-
-#### Clone the Github repository
-
-Clone the GitHub repository:
-
-```console
-git clone https://github.com/nexusformat/cnxvalidate.git
-```
-
-Enter the cloned repository via the command
-
-```console
-cd cnxvalidate
-```
-
-Create a new directory called `build` and enter it:
-
-```console
-mkdir -p build && cd build
-```
-
-Use `cmake` to configure and compile all functionalities of the software, especially external libraries such as the `xml2` and `hdf5` libraries.
-
-```console
-cmake ../
-```
-
-Install `cnxvalidate` after it was successfully build
-
-```console
-cd build
-make
-```
-
-Now, the executable is located at:
-
-```console
-/.../cnxvalidate/build/nxvalidate
-```
-
-You will also need to have a local copy of the NeXus definitions that you can point `cnxvalidate` to with the `-l` option.
-
-
-!!! info "Getting the NeXus definitions"
-    Download a set of NeXus definitions (choose only one).
-
-    For the NIAC NeXus definitions:
-
-    ```console
-    git clone https://github.com/nexusformat/definitions.git
-    ```
-
-    For the FAIRmat NeXus definitions, clone the repository:
-
-    ```console
-    git clone https://github.com/FAIRmat-NFDI/nexus_definitions.git definitions/
-    ```
-
-    Now you have a folder called "definitions". The path to this definitions folder is used in the `-l` option of `cnxvalidate` to tell the program which NeXus definitions shall be used.
+The tool `cnxvalidate` is written in C and has to be built from source (e.g., by using `cmake`). You can find instructions in the [README](https://github.com/nexusformat/cnxvalidate#building-nxvalidate) of the GitHub repository.
 
 ### Usage
 
-After installation, you can invoke the help call from the command line:
+After installation, you can invoke the help call for the executable (called `nxvalidate`) from the command line:
 
 === "Source"
     ```console

docs/learn/nexus/nexus-rules.md

@@ -56,12 +56,14 @@ A python implementation of this process can be found in [this function](https://
 
 Aside from these general rules, there are a number of special rules for NeXus names that need to be considered:
 
-- There is a set of reserved words (like `BLUESKY_`, `DECTRIS_`, `IDF_`, etc.) that are reserved for certain projects and communities. These are prefixes (typically written as uppercase + underscore) that cannot be overwritten by namefitting. For the full list, see [Rules for Storing Data Items in NeXus Files](https://manual.nexusformat.org/datarules.html), section "Reserved prefixes".
+- There is a set of prefixes (like `BLUESKY_`, `DECTRIS_`, `IDF_`, etc.) that are reserved for certain projects and communities. These prefixes (typically written as uppercase + underscore cannot be overwritten by namefitting.
 
-- There is also a set of reserved suffixes that are used to give additional information for a group or field. For the full list, see [Rules for Storing Data Items in NeXus Files](https://manual.nexusformat.org/datarules.html), section "Reserved suffixes".
+- There is also a set of reserved suffixes that are used to give additional information for a group or field. These can only be used if the original field is present as well. As an example, the field `temperature_set` - which uses the suffix `_set`, reserved for setpoint of field values - can only be present if the field `temperature` is present as well.
 
 - Additionally to namefitting, data annotation can use further information. For example, in case of NXdata, the axes listed among the `@axes` shall fit to any instances of `AXISNAME` and data objects listed in `@signal` or `@auxiliary_signals` shall fit to instances of `DATA`. Such rules are typically given in the base classes (e.g., see [here](https://manual.nexusformat.org/classes/base_classes/NXdata.html#index-0) for NXdata). Any tool that makes use of the base classes should implement these special rules in its validation procedure. As an example, pynxtools has a special [function for handling NXdata](https://github.com/FAIRmat-NFDI/pynxtools/blob/474fe823112b8ee1e7b42ac80bb7408fdde22bd5/src/pynxtools/dataconverter/validation.py#L220).
 
+For the full list of these respective rules, see [Rules for Storing Data Items in NeXus Files](https://manual.nexusformat.org/datarules.html).
+
 ## Concept name inheritance
 
 Note that NeXus also supports inheritance of concepts. The same rules as for instance names on the data level apply here for the inherited concept names. That is, the name of a concept must match in concept name and `nameType` to inherit from another concept. As an example, if we define a field with name `userID` and `nameType="partial"` in a base class and then use this base class in an application definition, the concept `user` and `nameType="specified"` would inherit its property. Contrarily, the concept `my_user` would not inherit from `userID`.

docs/learn/pynxtools/nexus-validation.md

@@ -4,9 +4,9 @@
 
 Validation is a processing step during which the structure, concepts, and annotations of data in a file are checked for conformance with a specific version of the NeXus definitions. The processing yields a list of deviations between the actual formatting of individual data instances and their expected formatting. These deviations are typically categorized based on their severity. In effect, boolean or more nuanced conclusions can be drawn how closely the content of the file follows the definitions.
 
-The validity of NeXus files is fundamental to ensure FAIR data. Without specific requirements, it is not possible to understand the data. What type of experiment? What Laser Wavelength? Which voltage? What data is represented in a table? What is the unit of a value? Which ISO norm does this refer to? Where was this measured? Which year was this measured?
+The validity of NeXus files is fundamental to ensure FAIR data. Validation ensures that key contextual information - such as the type of experiment, laser wavelength, applied voltage, structure of tabular data, units of measurement, referenced standards, measurement location, and acquisition time - matches the expected definitions and formats.
 
-The NeXus application definitions define the minimum set of terms/concepts that must be reported for a given experiment (i.e., the required terms that you must add to the NeXus file in order to be compliant with that application definition). Application definitions may also define terms that are optional in the NeXus data file. NeXus files are considered valid if they comply with the respective NeXus application definition.
+The NeXus application definitions define the minimum set of terms/concepts that must be reported for a given experiment (i.e., the required terms that you must add to the NeXus file in order to be compliant with that application definition). Application definitions may also define terms that are optional in the NeXus data file. Entries in NeXus files (which are instances of the [`NXentry`](https://manual.nexusformat.org/classes/base_classes/NXentry.html) base class) should report which definition they implement (under [`NXentry/definition`](https://manual.nexusformat.org/classes/base_classes/NXentry.html#nxentry-definition-field)). These entries are considered valid if they comply with the respective NeXus application definit Such an entry is valid if all required concepts of the respective application definition are present and if all instance data within the entry adheres to the format and constraints defined in the application definition.
 
 ## Approach