A document that carries other files inside it
Part 3 exists because a document sometimes has to carry another file inside it, and that file has to come back out years later, whole.
In plain words
Written for anybody, with nothing taken for granted. It says what the rule is for and what it changes on the document you end up with.
An electronic invoice is the clearest case: one document that is a page a person reads and, tucked inside it, the same amounts in a form accounting software reads without anybody retyping them. One file, one thing to keep, one thing to send.
It is not only invoices. A report can carry the spreadsheet its figures came from; a set of plans can carry the drawing they were produced from. The rule is the same each time: the carried file is named, described, dated, and listed where an ordinary reader will find it, so that opening the document is enough to get it back.
For a developer
The same thing without the detour: the objects, the constraints, and where the line falls between what is produced and what is declared.
Part 3 carries a file of any kind. Part 4 carries one only if that file is itself archival, and the level of part 4 made for carrying files takes any kind and asks for at least one — a document at that level with nothing attached is refused.
Written around each carried file: the stream itself, its size, its date, the name in both the plain and the Unicode forms, the description, the stated relationship, the media type, and the entry in the name tree that makes an ordinary reader show it in its attachments panel. Under an archival claim, a file that no page, picture or drawing has claimed for itself is listed on the catalogue as associated with the document as a whole.
Stated by you: the bytes, the file name, the description, the media type, the relationship the file bears to the document, and the modification date. The date is not read off the clock — a document built twice from the same inputs comes out byte for byte the same, and a clock would break that.
Clause by clause
The published text behind each requirement, what the engine measures the document against, and what it leaves to a validator.
No checksum and no creation date are written beside a carried file: neither is required, and neither is invented.
Whether a file carried under part 4 is itself archival is not read. A document carrying anything else claims the level made for carrying files, and a validator is what says whether that was right.
For an invoice, the name declared in the document's description and the name of the file actually carried are not compared. Keeping them equal is yours, and it is what a receiving system matches on.
What the engine does on its own
Nothing on this list has to be asked for. It comes out of a document that claims the standard, whatever else the calling program says.
- Writes the carried file with its size, its date and its media type, and names it in both forms so every reader agrees on the name.
- Registers it where an ordinary reader looks, so it shows in the attachments panel without anybody hunting.
- Lists it on the document as a whole, under an archival claim, when nothing else claims it.
- Refuses a document at the level for carrying files and carrying none.
What you supply
Nothing on this list can be guessed. The engine states what it was given and declines to invent the rest, which is why the document is refused rather than written with a value nobody chose.
- The bytes of the file, and the name it is to be found under.
- Its media type, and a description somebody reads.
- The relationship it bears to the document — source, alternative, data, supplement — which has no default because no default is right twice.
- Its modification date, stated rather than read off the clock.
The published texts behind it
| Published text | What it asks for |
|---|---|
ISO 19005-4 6.9 |
A document at the level for carrying files names the files it carries. |
The other families of requirements
Which part of the archiving standard to claim Every letter the document draws travels inside it Colours that mean the same thing on every device A page that comes out the same for everyone The document says what its marks stand for What the file says about itself Checking the claim, before and after
Glossary
- byte
- The unit a file's weight is counted in, the way a parcel is counted in grams. A thousand of them make a kilobyte, and a million make a megabyte — the size of one photograph taken with a telephone. A one-page PDF here weighs between six thousand and a hundred and twenty thousand, so a hundred of them fit in the space of five photographs.
- veraPDF
- A free program that checks whether a file really is what it claims to be, against the published rules. It is the tool archives use, so it is the one used here: a document is not called compliant because we say so, but because veraPDF passed it.
- Factur-X
- An invoice that is a page for a person and a data file for a machine, in one document. The page looks like any invoice; inside, the same amounts are attached in a form accounting software reads without anybody retyping them. French law requires this exchange between companies.
- attachment
- A whole file tucked inside a PDF and carried along with it, the way a paper clip holds a sheet to a folder. Opening the document is enough to get it back out. An electronic invoice works this way: the page a person reads carries the same amounts as a file accounting software reads.