+Input and output metadata is often involved during the DID Resolution, +DID URL Dereferencing, and other DID-related processes. The structure +used to communicate this metadata MUST be a map of +properties. Each property name MUST be a string. +Each property value MUST be a string, +map, list, +boolean, or null. +The values within any complex data structures such as maps and lists +MUST be one of these data types as well. +All metadata property definitions MUST define the value type, including any additional +formats or restrictions to that value (for example, a string formatted as a date or as a decimal integer). +It is RECOMMENDED that property definitions use strings for values where possible. +
+ ++All implementations of functions that use metadata structures as either input or output MUST +be able to fully represent all data types described here in a deterministic fashion. As inputs and +outputs using metadata structures are defined in terms of data types and not their serialization, +the method for representation is internal to the implementation of the function and is out of +scope of this specification. +
+ ++The following example demonstrates a JSON-encoded metadata structure represented +within a DID Resolution process. +
+ +
+{
+ "accept": "application/did+ld+json"
+}
+
+
+ +This example corresponds to a metadata structure of the following format: +
+ ++«[ + "accept" → "application/did+ld+json" +]» ++ +
+The next example demonstrates a JSON-encoded metadata structure that might be +used in the return of a DID Resolution process if a +DID was not found. +
+ +
+{
+ "error": "not-found"
+}
+
+
+ +This example corresponds to a metadata structure of the following format: +
+ ++«[ + "error" → "not-found" +]» ++