{"id":3488,"date":"2026-07-22T08:50:55","date_gmt":"2026-07-22T08:50:55","guid":{"rendered":"https:\/\/exponentialdecay.co.uk\/blog\/?p=3488"},"modified":"2026-07-22T08:50:55","modified_gmt":"2026-07-22T08:50:55","slug":"declarative-all-the-way-down-building-pronom-signatures-with-jsonid","status":"publish","type":"post","link":"https:\/\/exponentialdecay.co.uk\/blog\/declarative-all-the-way-down-building-pronom-signatures-with-jsonid\/","title":{"rendered":"Declarative all the way down: Building PRONOM signatures with JSONID"},"content":{"rendered":"

PRONOM signatures are a form of declarative language<\/a>, you describe the anticipated behavior in PRONOM’s regular expression syntax and tools like DROID, FIDO, and Siegfried will interpret those instructions and attempt to match them against different files to return a file format identification.<\/p>\n

Normally, you will write PRONOM signatures by hand but doing so for file formats based on other file format building blocks<\/a> can lead to inconsistencies. Bertrand Caron previously also recognized this<\/a> in the XML formats that are described with PRONOM signatures on Wikidata.<\/p>\n

XML can use single quotes '<\/code> (hex: 0x27<\/code>) and double quotes \"<\/code> (hex: 0x22<\/code>) for attribute data, and so, do we make a PRONOM signature with multiple sequences anticipating the use of either?<\/p>\n

The answer is more often than not likely to be yes<\/em>, because the appearance of these values are often helpful for identifying boundaries for strings that we know must exist.<\/p>\n

But the more file formats that we need to add to PRONOM that are based on foundational formats like XML, or JSON, or similar, the more inconsistencies will creep in, such as sequences that are looking specifically for one byte sequence over another.<\/p>\n

The issue extends further if file formats allow data to appear at the beginning of file, or we need to account for a variable amount of white-space, or we want to start thinking about multi-byte character encoding.<\/p>\n

We can, and in the XML issue described by myself and Caron, I think the recommendation is very much to create editorial standards for signatures for file formats based on other baseline, structured data formats like XML, JSON, YAML, and so on.<\/p>\n

And standards are well and good, but what if tooling could help us?<\/p>\n

For JSON this is exactly what I have tried to do in JSONID.<\/p>\n

What does this feature look like? And what does it get us? Let’s take a look.<\/p>\n

<\/p>\n

JSONID for PRONOM development<\/h2>\n

JSONID is described on COPTR<\/a> and I was able to introduce it at No Time To Wait in Dublin last year.<\/p>\n