Consistency of verapdf --list

[Reissner]

Currently, the result of verapdf --list is

veraPDF supported PDF/A and PDF/UA profiles:
  1a - PDF/A-1A validation profile
  1b - PDF/A-1B validation profile
  2a - PDF/A-2A validation profile
  2b - PDF/A-2B validation profile
  2u - PDF/A-2U validation profile
  3a - PDF/A-3A validation profile
  3b - PDF/A-3B validation profile
  3u - PDF/A-3U validation profile
  4 - PDF/A-4 validation profile
  4f - PDF/A-4F validation profile
  4e - PDF/A-4E validation profile
  ua1 - PDF/UA-1 validation profile
  ua2 - PDF/UA-2 + Tagged PDF validation profile
  wt1r - WTPDF 1.0 Reuse validation profile
  wt1a - WTPDF 1.0 Accessibility validation profile

I am sure that this has developpend evolutionary.
First, only PDF/A was supported only,
thus the norms are not called a-1b or accordingly, but just 1b.
Then PDF/UA was added and now one cannot just display 1 and 2,
but one must display ua1 and ua2.
But then it would be consequet, to display a1b and that like.
Then came the wt standards.
Still the headline is

veraPDF supported PDF/A and PDF/UA profiles:

not taking wt standards into account.

I would prefer just the form a-1b, ua-1 and wt-1r.

I am a bit a stakeholder:
I am writing a build tool now including checks via verapdf also.
It is mandatory to warn the user if the tool is not able to verify a specified standard.
This can be a PDF/X standard or it can be a new standard, hypothetical PDF/A-5x
with outdated verapdf.

If I implement a check independent of verapdf, this is badly maintainable.
Thus, at best I ask verapdf for the standards it supports.
This is almost realized by verapdf --list; the only problem is,
that this is too inhomogeneous.

For the time to be, I will parse each line, match against the regular expression

PDF/(?<sig>[A-Z]+-[0-9]+[A-Z]*)

and the signature is then the standard verapdf can verify.
But I am not sure whether this is kept stable. I doubt a bit.

[petervwyatt]

Request for terminology consistency: industry has settled on writing "PDF/A-2u" where the Level U conformance level is lowercase "u" when part of the subset moniker, but uppercase when described in free text (e.g., we write "The file is PDF/A-2, Level U conformance.") - and it's obviously uppercase in the XMP metadata. I know the case of the conformance levels are all over place but its been like this for more than 20 years with PDF/X - I believe this was so that the subset letter "A" (always uppercase) is more easily distinguished from one or more conformance levels (lower case).

Can veraPDF please adjust is output text?

[bdoubrov]

@Reissner thanks a lot for your comment. Unfortunately, for backward compatibility it is very difficult to modify the property values. We can however easily modify the descriptions (=output of the command verapdf --list ) to make them easier to parse. Would it resolve you issues?

And as indicated by @petervwyatt we need to change PDF/A-1A to PDF/A-1a and similar anyway.

[Reissner]

I think, I shall treat differently: from
1a - PDF/A-1A validation profile
extract the word after - which is PDF/A-1a with proper casing.
so nothing to change for you, well except casing.