ISO standardized subset detection does not account for XMP amendments or dated revisions fields

[petervwyatt]

The XMP identification metadata for ISO standardized subsets of PDF such as PDF/A and PDF/UA define additional fields which must also be checked, since future ISO publications such as amendments and dated revisions may alter the definition of current ISO standards.

For example, pdfuaid:amd (as text string: amendment part, COLON, 4 digit year = n:year) and pdfuaid:rev (as 4-digit integer year) must be checked as well as pdfuaid:part to ensure that the correct set of supported validation rules are applied. If these fields contain unexpected values then veraPDF should report a warning, since the amendment or dated revision might modify the current set of rules.

This applies to both PDF/A and PDF/UA - for example:

• the current draft of PDF/A-4 is allowing certain types of embedded files to NOT require the PDF/A-4f conformance level and this will only be detectable via a value of pdfaid:rev that is not 2020 (we don't know the actual year yet).

• in Berlin, there was also a proposal for a PDF/UA-1 amendment to relax two specific rules - these changes would only be valid if pdfuaid:amd is 1:202x (year is obviously unknown at this time).

So the presence of any unexpected values in pdfxxid:rev or pdfxxid:amd (and technically every other XMP identification metadata field: conformance, corr, part, etc.) should trigger some sort of hesitation/warning that the validation results may be incorrect, since veraPDF is processing a PDF file claiming conformance to something veraPDF doesn't support.

Some synthetic PDF/UA test files you can use for testing are at https://pdfa.org/wp-content/uploads/2025/09/UA-XMP.zip

[bdoubrov]

@petervwyatt as far as I can see, the only valid values of these properties right now are:

PDF/A-1: amd=null, 1:2007, 2:2011 (here null means absence of this property in XMP)
PDF/A-2: amd=null
PDF/A-3: amd=null
PDF/A-4: rev=2020

PDF/UA-1: amd=null, 1:2014
PDF/UA-2: rev=2024

Of course, as soon as new amendments / dated revisions are out, more values will become valid.

Is this list correct?

[petervwyatt]

@bdoubrov - you have a typo for ISO 19005-1:2005/COR 2:2011 - that should be amd=2:2011.

I don't believe that PDF/UA-1:2014 changed anything since this was NOT an amendment, but a new edition done as a dated revision. Thus I think pdfuaid:amd=null always and there is no way via XMP of knowing if a UA-1 file was created against one of the 2012 editions (there were 2 2012 editions just a few months apart - I think the only difference was that the 2nd edition was itself tagged), or the 2014 edition since pdfuaid:rev (year) was not defined in UA-1. And I can't remember what changed in UA-1 between the 2012 and 2014 editions...

As you know, very soon we'll also have PDF/A-4 pdfaid:rev=2026 (I don't believe ISO processes are quick enough to complete this in 2025 as DIS ballots are 20 weeks!) and possibly PDF/UA-1/Amd1, pdfuaid:amd=1:202x longer term.

And null should equivalently cover both not present in XMP and empty (blank) fields, such as <pdfuaid:amd> </pdfuaid:amd>.

And don't forget to check for bad pdfaid:conformance entries too!

[DuffJohnson]

Concur that there's no way to tell between 2012 and 2014 based on metadata.

Diff between 2012 and 2014 is listed in the Forward to 2014. The changes are minor and most are editorial. The normative change is a loosening.

I guess a 2012-based validator could fail a PDF/UA-2014 document based on the lack of a Scope in TH cells, but 2012 was explicitly cancelled by 2014...

[bdoubrov]

And null should equivalently cover both not present in XMP and empty (blank) fields, such as <pdfuaid:amd> </pdfuaid:amd>.

Well, I'd say empty <pdfuaid:amd> </pdfuaid:amd> would be invalid. If this property is present, it should comply to the requirements of 14289-1: "... the value of pdfuaid:amd shall be the amendment number and year, separated by a colon."

So, null is really reserved to indicate that this property is not present (which is OK).

[petervwyatt]

I don't agree with "if present then..." as the PDF/A specs state "optional", not "required if ...".

[bdoubrov]

@petervwyatt

Here is the complete citation from ISO 14289-1:

If the file conforms to a version of this International Standard that is defined by an amendment to a part, then the value of pdfuaid:amd shall be the amendment number and year, separated by a colon.

I don't think an empty string would be a valid value for pdfuaid:amd. I do agree it is optional, but when it is present, it must follow the pattern "the amendment number and year, separated by a colon". Or have I misunderstood your comment?

[petervwyatt]

I agree that any value present must follow the defined pattern. But I think just the open and close XMP tags without any value whatsoever is also acceptable as valid since that is also clearly indicating no amendment specified - and this corresponds to the expected behavior for DC fields like Subject, etc. whicg are often always present even when empty.

[bdoubrov]

rev entry needs to be present and validated.
amd is optional and is not subject to validation

[MaximPlusov]

The new rules added in the latest dev version.