demo/validator
1
0
Fork 0
mirror of https://github.com/itplr-kosit/validator.git synced 2026-05-25 16:55:39 +00:00
Code Issues Projects Releases Packages Wiki Activity

Translation, add seq. dia, separation of concerns

Browse source
This commit is contained in:
Renzo Kottmann 2019-06-21 15:37:26 +02:00
parent f4c1afb065
commit f073924a8a
1 changed files with 32 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

65
docs/architecture.md
View file

@ -1,51 +1,44 @@
# General Architecture # General Architecture
The validator itself is just an engine which executes validation according to a certain configuration (see [configuration documentation](configuration.md)) The validator itself is just an engine which executes validation according to a certain configuration (see [configuration documentation](docs/configurations.md)).
The validator takes a sceanrio.xml and the configured directory with all artifacts necessary for validation (scenario repository). Then it performs
the validation and generates a report in XML format. This report is then the input to an XSLT provided by the configuration.
## Separation of concerns
* The purpose of the validator is to only report if an XML instance is valid or not
* A configuration can provide an XSLT which takes the validator report and generates an own report
* This report may choose to conclude acceptance of the XML instance or not
The validator reports valid/invalid, a configuration reports acceptance/rejection!
## General process
The general process is like this:
```mermaid ```mermaid
sequenceDiagram sequenceDiagram
participant e as Validator participant e as Validator
participant c as Configuration participant c as Configuration
e ->> c: Read scenario.xml e->>+c: create ScenarioRepository
e ->> c: Pick validation artifacts c->>-e: is available
e->>e: parse XML
e->>e: select scenario
e->>e: validate XSD
e->>e: validate Schematron
e->>e: create Validator Report
e->>+c: execute configuration report generator
e->>-c: return XPATH of acceptance message
``` ```
1. *XML-Parsing*: Is the XML instance valid in the basic sense. If not, validation is stopped and the validator report is returned with status *invalid*.
Eine zu prüfende Datei durchläuft die folgenden Schritte 2. *Identifikation of applicable scenario*: The configuration must have a defined scenario which matches the XML instance (it is an XPATH expression). If no scenario matches, validation is stopped and the validator report is returned with status *invalid*.
3. *XML-Schema validation*: The XML instance must be valid according to the configured XSD. If not, validation is stopped and the validator report is returned with status *invalid*.
4. *Schematron validation*
Eine zu prüfende Datei durchläuft die folgenden Schritte 5. *Aggregation of validation results*: All results are aggregated into the validation report:
* In case there is a single *error* or *warning* the report will have status erhält*invalid*, otherwise the status will be *valid*.
1. *Grundsätzliche XML-Prüfung*: Es muss sich bei der zu prüfenden Datei um wohlgeformtes XML handeln, andernfalls
werden keine weiteren Prüfungen durchgeführt und ein [Prüfbericht] mit Status *invalid* und Empfehlung
*reject* generiert.
2. *Identifikation des anzuwendenden Prüfszenarios*: Für den Dokumenttyp der zu prüfenden XML-Datei muss in der
[Konfigurationsdatei](#konfiguration-des-prüftools) ein Prüfszenario definiert sein (die Identifikation des
Dokumenttyps erfolgt durch einen XPath-Test), andernfalls werden keine weiteren Prüfungen durchgeführt und ein
[Prüfbericht] mit Status *invalid* und Empfehlung *reject* generiert.
3. *Prüfung gegen das XML-Schema des identifizierten Dokumenttyps*: Das zu prüfende Dokument muss valide bzgl. des
Schemas sein, andernfalls werden keine weiteren Prüfungen durchgeführt und ein [Prüfbericht] mit Status *invalid*
und Empfehlung *reject* generiert.
4. *Prüfung gegen die Schematron-Regeln des identifizierten Dokumenttyps*
5. *Aggregation und Bewertung der einzelnen Prüfungen* zu einem [Prüfbericht]: Die Ergebnisse der
vorherigen Schritte werden in einem einheitlichen Berichtsformat zusammengefasst und bewertet:
* Sofern mindestens einer der zuvor durchgeführten Prüfschritte einen Fehler (*error*) oder eine Warnung (*warning*)
geliefert hat, erhält der Prüfbericht den Status *invalid*, andernfalls erhält er den Status *valid*.
* Sofern einer der Prüfschritte einen Fehler geliefert hat, erhält der Prüfbericht grundsätzlich die Empfehlung
*reject*, andernfalls erhält er die Empfehlung *accept*.
* In der [Konfigurationsdatei](#konfiguration-des-prüftools) kann für einzelne Prüfregeln festgelegt werden, dass
sie für die Bewertung einer [anderen Meldungsart](#anpassung-der-fehlergrade-für-die-bewertung) zuzuordnen sind
(z. B. *warning* anstelle von *error*).
* Der Prüfbericht ist ein für die maschinelle Auswertung geeignetes XML-Dokument. Darin eingebettet ist auch eine
für menschliche Leser bestimmte HTML-Aufbereitung des Prüfergebnisses. Die Details dieser HTML-Aufbereitung können
bei Bedarf [angepasst](#anpassung-der-html-ausgabe) werden.