One list of all JHOVE message IDs

[RvanVeenendaal]

Now that all JHOVE messages have an ID, could you please publish all IDs plus messages in one linkable location? This could e.g. be a source file or a wiki page, or something/somewhere else.

At OPF #OAG3 in Helsinki plans were discussed to work on definitions, explanations, etc. for messages. Having a list of all messages in one location facilitates linking to those IDs plus messages.

[asciim0]

Quick question - do you expect the info that can be already found in the modules error message files? like this for pdf: https://github.com/openpreserve/jhove/blob/94da570caa55759354fa6fcd50e4ea7edbba1e7d/jhove-modules/pdf-hul/src/main/resources/edu/harvard/hul/ois/jhove/module/pdf/ErrorMessages.properties

[RvanVeenendaal]

Yes, at least that to start with and assuming it can be automatically kept up to date. Alternatives are perhaps possible, again if kept up to date.

[ross-spencer]

If I understand correctly - then it is possible to write a GitHub action to extract and format the information as new commits are pushed if that interests anyone? It would simply result in a second commit to that file by the bot action, but then Docs/Code would be kept in sync.

[RvanVeenendaal]

I guess so @ross-spencer - I'm not that familiar with GitHub's features. Please cross-reference with https://github.com/openpreserve/jhove/issues/859, which might also help understand what I'm trying to achieve. It seems to me that the community is ready to add their impact assessments and resolutions (or further analyses, preservation plans and actions) to JHOVE error IDs/messages. My idea is that the JHOVE error IDs/messages and perhaps the general 'best practice' impacts and remediations on the hul wiki pages should act as an in synch (closed) vocabulary to link to from whichever JHOVE errors and warnings 'database' we as community will develop. Each JHOVE-using organisation may have different ideas about 'how bad it is' and 'what to do about it', but they all start from the same IDs/messages.

[ross-spencer]

Thanks @RvanVeenendaal +1 for both #859 and what I do think you're asking for here. Rather than offer a solution, perhaps a better way of phrasing my suggestion is that one way to keep these two parts code+docs in-sync is to trigger an action/activity that happens when code changes, e.g. when errors are updated/deleted/added they are crawled in the code-base by a crawler, and then output in human-readable markdown/html, and also committed to the code-base. One way to achieve this may be through continuous integration, but other publishing workflows could also be investigated.