clarifying predicate Ignore

[bdoubrov]

The predicate fn:Ignore is currently defined using the phrase "is to be ignored", which allows several interpretations.

In particular, does it mean that all other Arlington conditions (such as value type, special cases, etc) are not applicable to the ignored property? What about any links from such property? Do they need to be followed or also ignored?

[petervwyatt]

For fn:Ignore(...) (with a condition argument), it means that the PDF spec explicitly states that the key is defined to be ignored under specific conditions.

For fn:Ignore() (no argument) it means that the PDF spec explicitly defines the key (and possibly some other data integrity rules) but then also states it should be ignored or words to that effect (e.g. "shall not be used", etc). In one case, the PDF spec states such a key is deprecated, but not in others.

Remember Arlington's goal is to reflect the PDF spec as written. But what "ignored" (or "not used") means for useful file validation is a very good next question! 😁

It would be nice if a validator reported an out-of-spec entry regardless (even if it would be conditionally ignored) because PDFs can/do get edited and that editing may make things then invalid. And it can help PDF writers reduce file size by not writing unnecessary entries.

This wording ambiguity is similar to PDF Errata 6 and PDF Errata 118.

[bdoubrov]

I suggest to keep this discussion open (in the scope of Arlington!) until PDF Errata 6 is resolved. For example, one of the latest comments there says:

I interpret "... shall be ignored if ..." as a clearer statement since this also implies that validators shall(!) not report the key or key value under the stated condition (so even if it was invalid it is technically not a reportable error because of the presence of the other key).

[petervwyatt]

As you would know from our PDF/A discussions, I have since come to realise that "validators" are not "conforming processors" by definition (I know we don't officially use that term in 32K, but there still needs to be scoping of processors).

Maybe such statements in 32K should be refined/narrowed along the lines of "shall not be used for thing" or "shall be ignored when thing" where thing might be localized to "rendering", "signature validation", "form interaction", or some other aspect of using PDF for a very specific feature that is not inferred to be the all-encompassing parsing or validating.