DefHash - Define things according to a specification, using hashes


This document describes version 1.0.10 of DefHash (from Perl distribution DefHash), released on 2015-04-24.




This document describes DefHash, a specification for using hashes to define things. DefHash was born out of several other projects/specifications like Sah, Rinci, Riap, Module::Patch.


In this document, hashes are written in JSON or pseudo-JSON (e.g. contains ellipsis ... or JavaScript-style comments // ...).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL "NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


  • defhash

    A regular hash, or dictionary (as it is called in Python), or associative array (as it is called in PHP), or object (as it is called in JavaScript). A defhash has properties, which translates to the hash key/value pairs. Property names translates to hash keys, while property values translates to hash values. The same hash key/value pairs are used to store property attributes:

         "v": 1,                         // set value for property 'v'
         "prop1": "value1",              // set value for property 'prop1'
         "prop2": ["value2", ...],       // set value for property 'prop2'
         "prop1.attr1": ...,             // set value for prop1's attribute
         "prop1.attr1.subattr1": ...,    // set value for prop1's attribute
         "_extra1": ...,                 // ignored property, starts with _
         "prop1._extra_attr": ...,       // ignored attribute, starts with _
         "prop(en)",                     // equivalent/normalizable to prop.alt.lang.en

    The above defhash defines two properties: prop1 and prop2. prop1 has two attributes, attr1 and attr1.subattr1. Properties with names starting with underscore (_) are ignored; this can be used to put extra information. Likewise for attribute names which start with underscore.

    Property names must follow this regex '\A[a-z][a-z0-9_]*\z' (an Lowercase-alphanumeric-only word). Property attributes must follow this regex: '\A[a-z][a-z0-9_]*(\.[a-z][a-z0-9_]*)*\z' (a dotted lowercase-alphanumeric word). An exception is some shortcuts which will be normalized during further processing: "foo(LANG)" is a shortcut for "foo.alt.lang.LANG".

    Property value can be anything. It can contain another defhash for defining subentities, for example. In Rinci, a function metadata has a property called args to define function arguments; its value is a hash of argument names and argument specification. Each argument specification is a defhash.

    Property attributes can be used to store extra data into a property.

    The hash itself can have attributes, stored in .<attr> keys:

         ".attr1": ...,
         ".attr2.subattr": ...,
         "._ignored": ...
  • specification

    A set of recognized properties and property attributes, including whether the properties are required, expected values (schema) for properties and attributes, and default values.

    For example, Rinci is a specification for function metadata (among others). One writes a defhash (metadata) for a function, it contains properties to describe the function. Rinci specifies what properties are available and the meaning and expected values for each of those properties. An example of a Rinci function metadata:

     // metadata for function 'sum'
         "v": 2, // version of Rinci specification
         "summary": "Sum all the elements of array numerically",
             "Non-numeric elements in array will be skipped. Empty array
              or no numeric elements in array will result in 0 for the
         "args": {
             "array": {
                 "summary": "The array to sum",
                 "schema": "array*",

Why write definitions in a defhash?

Hash is a basic data structure that is supported by all high-level languages, including Perl, Python, PHP, Ruby, and JavaScript. It is particularly easy to merge. It makes checking the existence of value of property very easy, by just accessing the hash's key.

... instead of text (like POD)? Putting definition in a data structure makes it easier to manipulate the definition (merge, parse, normalize, convert, etc).

... instead of array? Hash allows us to evolve more easily. If we deprecate a property or add new ones, elements don't have to shift like in array.

... instead of a regular or nested hash? Well, defhash is a regular hash. It is just a convention to limit the range of valid keys (only alphanumeric characters) in exchange for additional metadata for each key (which is stored as regular keys in the same hash). Plus it establishes convention for some predefined properties and attributes.

Common properties

These are the list of properties that all specifications must recognize:

  • v => FLOAT (default: 1)

    This specifies the version of specification that the defhash is following.

    A specification can change over time. The v property specifies the specification version which the hash follows. Specification version is a non-negative real number, but integer is recommended. If unspecified, it is assumed to be 1. It can also be 0.

  • defhash_v => INT (default: 1)

    This specifies the version of DefHash specification itself. It is hoped that this should never change, so normally a defhash need not specify this.

  • name => TEXT

    A short (usually single-word) name for the thing that is described. For example, in Rinci function metadata, it is the function's name. In Sah, it is a name of the schema that can be used by the human compiler.

     // metadata for function 'sum'
         "name": "sum",
     // schema for describing positive integer
     ["int", {
         "name": "pos_int",
         "min": 0,
  • caption => text

    Like name, but for display purposes.

  • summary => TEXT

    A short (< 72 character), one-line summary about the thing that is described. For example, in Rinci function metadata, the summary describes what the function does:

     // metadata for function 'sum'
         "summary": "Sum all the elements of an array numerically",
  • description => TEXT

    A longer description. Normally a paragraph or longer of text. The text is assumed to be marked up in Markdown.

  • tags => ARRAY[TEXT | DEFHASH]

    A list of one or more tags, can be used to categorize the thing that is described. Example:

     "tags": ["important", "category:filtering", "category:filtering-for-foo"],

    Each tag can also be a defhash for more detailed specification:

     "tags": ["important",
              {"name":"category:filtering", "summary":"filtering field"},
              {"name":"category:filtering-for-foo", "summary":"filtering for field 'foo'"}]
  • default_lang => TEXT

    Default language. Defaults to parent's value, or if parent does not exist, from environment LANG, or if undefined or C, en_US.

  • x => ANY

    This property is used to store extended (application-specific) attributes, much like the X- prefix in HTTP or email headers. This property can be used as an alternative to using underscore prefix (e.g. _foo). Some processing tools strip properties/attributes that begin with underscores, so to pass extended metadata around, it might be more convenient to use the x property.


         "" => 1,
         "" => "some value",

Property attributes

Below is the list of property attributes that must be supported.

  • alt

    This attribute can be used to store alternate property values. The most common is alternative language (alt.lang.LANG_CODE), where you want to provide translations. Example:

         "summary": "An English summary",
         "summary.alt.lang.id_ID": "Ringkasan dalam bahasa Indonesia",

    There is a shortcut form for alt.lang, which should be normalized to alt.lang when processing:

         "summary": "An English summary",
         "summary(id_ID)": "Ringkasan dalam bahasa Indonesia",

    Another kind of alternate is environment (alt.env.NAME), for example we might want to use different summary when displayed in a CLI program vs web application. Example (in a Rinci function argument's specification):

         "summary.alt.env.cmdline": "Like --foo, do something foobar-ish",
         "summary.alt.env.web": "Like the `foo` field, do something foobar-ish",

    Another kind of alternate is boolean logic (alt.bool.WHICH, where WHICH can be not), when you want to specify the negative sense/sentence instead of the regular positive one. Example (in a Rinci function argument's specification):

     "tcp": {
         "schema": "bool",
         "default": true,
         "summary": "Parse TCP connections",
         "summary.alt.bool.not": "Do not parse TCP connections",

    Another kind of alternate is grammatical variance based on noun plurality (alt.plurality.WHICH where WHICH can be singular or plural). Example (in a Rinci function argument's specification, where an array argument like files translates in a CLI environment to multiple --file option specification):

     "files": {
         "schema": ["array*", {"of":"str*"}],
         "summary": "Specify one or more files to check",
         "summary.alt.plurality.singular": "Add a file to check (can be specified multiple times)",

    Combination of alternates. When two or more alternates is combined, they must be ordered asciibetically and separated with an underscore _. For example:

         "default_lang": "en_US",
         "summary": "An English summary",
         "summary.alt.env_lang.web.id_ID":"(Summary in Indonesian, for web)",
         "summary.alt.env_lang.cmdline.id_ID":"(Summary in Indonesian, for cmdline)"

When should specification version be increased?

When a backward-incompatible change is introduced. This is defined to be removal of a recognized property, or the semantic change of an existing property, or other incompatible change. For example,

 XXX (modp 1->2, 2->3; ri ->2, not using defhash but that is not the real reason, removal of features property)
 XXX riap also bumped to 2 just because it uses hash


Semantic Versioning,

Markdown specification


Please visit the project's homepage at


Source repository is at


Please report any bugs or feature requests on the bugtracker website

When submitting a bug or request, please include a test-file or a patch to an existing test-file that illustrates the bug or desired feature.


perlancar <>


This software is copyright (c) 2015 by

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.