Create a TxMetadataValue from a Text as a list of chunks of an acceptable size.

Create a TxMetadataValue from a ByteString as a list of chunks of an accaptable size.

Validate transaction metadata. This is for use with existing constructed metadata values, e.g. constructed manually or decoded from CBOR directly.

An error in transaction metadata due to an out-of-range value.

Tx metadata is similar to JSON but not exactly the same. It has some deliberate limitations such as no support for floating point numbers or special forms for null or boolean values. It also has limitations on the length of strings. On the other hand, unlike JSON, it distinguishes between byte strings and text strings. It also supports any value as map keys rather than just string.

We provide two different mappings between tx metadata and JSON, useful for different purposes:

1. A mapping that allows almost any JSON value to be converted into tx metadata. This does not require a specific JSON schema for the input. It does not expose the full representation capability of tx metadata.
2. A mapping that exposes the full representation capability of tx metadata, but relies on a specific JSON schema for the input JSON.

In the "no schema" mapping, the idea is that (almost) any JSON can be turned into tx metadata and then converted back, without loss. That is, we can round-trip the JSON.

The subset of JSON supported is all JSON except: * No null or bool values * No floating point, only integers in the range of a 64bit signed integer * A limitation on string lengths

The approach for this mapping is to use whichever representation as tx metadata is most compact. In particular:

• JSON lists and maps represented as CBOR lists and maps
• JSON strings represented as CBOR strings
• JSON hex strings with "0x" prefix represented as CBOR byte strings
• JSON integer numbers represented as CBOR signed or unsigned numbers
• JSON maps with string keys that parse as numbers or hex byte strings, represented as CBOR map keys that are actually numbers or byte strings.

The string length limit depends on whether the hex string representation is used or not. For text strings the limit is 64 bytes for the UTF8 representation of the text string. For byte strings the limit is 64 bytes for the raw byte form (ie not the input hex, but after hex decoding).

In the "detailed schema" mapping, the idea is that we expose the full representation capability of the tx metadata in the form of a JSON schema. This means the full representation is available and can be controlled precisely. It also means any tx metadata can be converted into the JSON and back without loss. That is we can round-trip the tx metadata via the JSON and also round-trip schema-compliant JSON via tx metadata.

Convert a value from JSON into tx metadata, using the given choice of mapping between JSON and tx metadata.

This may fail with a conversion error if the JSON is outside the supported subset for the chosen mapping. See TxMetadataJsonSchema for the details.

Convert a tx metadata value into JSON , using the given choice of mapping between JSON and tx metadata.

This conversion is total but is not necessarily invertible. See TxMetadataJsonSchema for the details.

A family of singleton types used in this API to indicate which type to use where it would otherwise be ambiguous or merely unclear.

Values of this type are passed to deserialisation functions for example.