Target.tsv test for in EmbeddedFiles NameTree

[faceless2]

Coming back to Target.tsv - already been touched in in #38 and #49

For the N key you are checking

fn:Eval(fn:Not(fn:IsPresent(fn:Not((@R==C) && fn:InNameTree(trailer::Catalog::Names::EmbeddedFiles)))))

to capture the requirement in table 205

(Required if the value of R is C and the target is located in the EmbeddedFiles name tree; otherwise, it shall be absent) The name of the file in the EmbeddedFiles name tree.

This requirement can't be verified if the target link is to an embedded file within an embedded file, which is valid (and I have an example if you want it) - it contains this action, referencing the embedded-file "bob.pdf" attached to the embedded-file "charlie.pdf"

<</Type/Action/S/GoToE/D(banana1)/T<</R/C/N(charlie.pdf)/T<</R/C/N(bob.pdf)>>>>>>

One way to fix this is to

1. split Target.tsv into Target.tsv and TargetEmbedded.tsv
2. in Target.tsv, change T from [Target] to [TargetEmbedded]
3. remove any checks in TargetEmbedded.tsv that refer to properties of the PDF, such as InNameTree, NumberOfPages etc., as all these tests would need to be run on the target PDF, not the current PDF.

[petervwyatt]

@faceless2 - could I please get the test file so I can test the changes?

[faceless2]

Indeed! There's one at https://bfo.com/misc/notarizing-signatures/dave.pdf - this has other Arlington issues, but there are two actions in there which are currently being caught by this one (objects 23 and 24).

(context for the file is at https://bfo.com/misc/notarizing-signatures/version2.html)

[petervwyatt]

Interesting PDF. I also created Errata #382 as a result of poking around...

It is the only place in the Arlington model where fn:StringLength was used on something that was not string-byte!

[petervwyatt]

On review, I also think we have a rule stating that if @R==C and if key P is present, then A must also be present (and vice-versa) because both P and A have the same identical conditional requirement in Table 205. However, since files of file annots are not required to be in the EmbeddedFiles name tree then there is nothing additional about N that can be specifically asserted beyond that one of N, P and A must always exist.

ie. for P: fn:IsRequired((@R==C) && fn:IsPresent(A))
ie. for A: fn:IsRequired((@R==C) && fn:IsPresent(P))
ie. for N: fn:IsRequired(fn:Not(fn:IsPresent(P) || fn:IsPresent(A)))