Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stronger validation against schema #64

Open
christofs opened this issue Mar 3, 2018 · 1 comment
Open

Stronger validation against schema #64

christofs opened this issue Mar 3, 2018 · 1 comment

Comments

@christofs
Copy link
Collaborator

christofs commented Mar 3, 2018

"Es wäre schön, wenn man im DH-Convalidator ein von der Konferenz angelegtes XSD 1.1-Schema ablegen könnte, gegen das die TEI-Konversion validiert wird. Der Convalidator könnte dann die Konversion zusammen mit dem Validierungsergebnis zurückschreiben, oder die Konversion ganz verweigern und das Validierungsergebnis anzeigen.

Das schwebt mir gerade vor. Mildere Varianten mit "Teste, ob die Bibliographie mindestens ein hat etc. sind natürlich auch denkbar."

@mpetris
Copy link
Contributor

mpetris commented Mar 5, 2018

Should be relatively easy to implement. There is already a schema validation against a built in schema which can be switched on/off via the performSchemaValidation property set to true/false. The built in schema is a Roma generated schema with the four core modules plus figures (with an adjusted content model to allow MathML) taken from the template "TEI with MathML" plus persName, surname, forename and affiliation of module namesdates and anchor of module linking. Making the location of the schema configurable via a property should be sufficient.

Currently when configured to do validation the DHConvalidator denies further processing of documents which failed the validation and displays the validation result, i. e. the reason for the failure. So far so good, but the validation is performed as a last step so what gets validated is the result of the OxGarage conversion with a bit of DHConvalidator postprocessing. That means the input to the validation is unknown to the user so that any reference to it in the failure report is not very helpful unless someone is in debug mode an has insight to these intermediate results. To improve this, the input to the validation could be displayed along with the error messsage. This still might not be helpful to every user but at least an administrator would get more insight to help the enduser. This is related to #50 and #51 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants