As a data archivist/validator, I want to ease the sifting of error logs with two types of output reports

[scholes-ds]

Checked for duplicates

Yes - I've already checked

🧑‍🔬 User Persona(s)

Data archivists, validators, data providers

💪 Motivation

when a large number of errors are found, this may simplify tracking down and resolving issues

📖 Additional Details

1. It would be helpful to have a published table (if possible) of error categories examples: [error.table.missing_CRLF], [error.label.schematron], etc. The table could have descriptions and possibly identifier numbers assigned.
2. There could be an option to output a minimal and extended log.
3. The user could configure which error messages to limit from the minimal log file by either their [names] or ID's. The count of these findings could still be included, but not the instances. This way those known error messages are suppressed from the minimal log, so they can focus on tracking down other issues. The extended log would still include all the findings.

Acceptance Criteria

Given
When I perform
Then I expect

⚙️ Engineering Details

No response

🎉 I&T

No response

[al-niessner]

1. We can easily publish a list of all error codes - note that error.label.schema is the error code - but there are no descriptions.
2. see answer to (3)
3. You can use grep -v to do what you want. If you want to remove all of the 'error.label.schema' because you think you fixed them, then do grep -v error.label.schema full.log > filtered.log. You now have as many filtered logs as you want for any errors you want without waiting for validate to reprocess large bundles.