Merge pull request #832 from kaleido-io/fix-docs-links

Fix relative links in reference descriptions docs

docs/reference/types/_includes/blockchainevent_description.md

@@ -1,9 +1,9 @@
 Blockchain Events are detected by the blockchain plugin:
 
-1. When a [ContractListener](./(contractlistener.md) has been
+1. When a [ContractListener](./contractlistener.html) has been
    configured against any custom smart contract through the FireFly API
 2. Indirectly via a Token Connector, which understands the correct events
-   to listen to for a [Token Pool](./(tokenpool.md) configured against a
+   to listen to for a [Token Pool](./tokenpool.html) configured against a
    standard such as ERC-20/ERC-721/ERC-1155
 3. Automatically by FireFly core, for the BatchPin contract that can
    be used for high throughput batched pinning of off-chain data transfers

docs/reference/types/_includes/event_description.md

@@ -13,8 +13,8 @@ order that they are delivered to your application.
 ### Reference
 
 Events have a `reference` to the UUID of an object that is the subject of the event,
-such as a detailed [Blockchain Event](./(blockchainevent.md), or an off-chain
-[Message](./(message.md).
+such as a detailed [Blockchain Event](./blockchainevent.html), or an off-chain
+[Message](./message.html).
 
 When events are delivered to your application, the `reference` field is
 automatically retrieved and included in the JSON payload
@@ -44,14 +44,14 @@ the type of event. This is intended to be a property you would use to
 filter events to your application, or query all historical events
 associated with a given business data stream.
 
-For example when you send a [Message](./(message.md), you set the `topics`
+For example when you send a [Message](./message.html), you set the `topics`
 you want that message to apply to, and FireFly ensures a consistent global
 order between all parties that receive that message.
 
 ### Transaction
 
 When actions are submitted by a FireFly node, they are performed
-within a FireFly [Transaction](./(transaction.md). The events that occur
+within a FireFly [Transaction](./transaction.html). The events that occur
 as a direct result of that transaction, are tagged with the transaction
 ID so that they can be grouped together.
 
@@ -74,24 +74,24 @@ Note that some events cannot be tagged with a Transaction ID:
 
 | Types                                       | Reference                            | Topic                       | Correlator              |
 |---------------------------------------------|--------------------------------------|-----------------------------|-------------------------|
-| `transaction_submitted`                     | [Transaction](./(transaction.md)         | `transaction.type`          |                         |
-| `message_confirmed`<br/>`message_rejected`  | [Message](./(message.md)                 | `message.header.topics[i]`* | `message.header.cid`    |
-| `token_pool_confirmed`                      | [TokenPool](./(tokenpool.md)             | `tokenPool.id`              |                         |
-| `token_pool_op_failed`                      | [Operation](./(operation.md)             | `tokenPool.id`              | `tokenPool.id`          |
-| `token_transfer_confirmed`                  | [TokenTransfer](./(tokentransfer.md)     | `tokenPool.id`              |                         |
-| `token_transfer_op_failed`                  | [Operation](./(operation.md)             | `tokenPool.id`              | `tokenTransfer.localId` |
-| `token_approval_confirmed`                  | [TokenApproval](./(tokenapproval.md)     | `tokenPool.id`              |                         |
-| `token_approval_op_failed`                  | [Operation](./(operation.md)             | `tokenPool.id`              | `tokenApproval.localId` |
-| `namespace_confirmed`                       | [Namespace](./(namespace.md)             | `"ff_definition"`           |                         |
-| `datatype_confirmed`                        | [Datatype](./(datatype.md)               | `"ff_definition"`           |                         |
-| `identity_confirmed`<br/>`identity_updated` | [Identity](./(identity.md)               | `"ff_definition"`           |                         |
-| `contract_interface_confirmed`              | [FFI](./(ffi.md)                         | `"ff_definition"`           |                         |
-| `contract_api_confirmed`                    | [ContractAPI](./(contractapi.md)         | `"ff_definition"`           |                         |
-| `blockchain_event_received`                 | [BlockchainEvent](./(blockchainevent.md) | From listener **            |                         |
-| `blockchain_invoke_op_succeeded`            | [Operation](./(operation.md)             |                             |                         |
-| `blockchain_invoke_op_failed`               | [Operation](./(operation.md)             |                             |                         |
-
-> * A separate event is emitted for _each topic_ associated with a [Message](./(message.md).
+| `transaction_submitted`                     | [Transaction](./transaction.html)         | `transaction.type`          |                         |
+| `message_confirmed`<br/>`message_rejected`  | [Message](./message.html)                 | `message.header.topics[i]`* | `message.header.cid`    |
+| `token_pool_confirmed`                      | [TokenPool](./tokenpool.html)             | `tokenPool.id`              |                         |
+| `token_pool_op_failed`                      | [Operation](./operation.html)             | `tokenPool.id`              | `tokenPool.id`          |
+| `token_transfer_confirmed`                  | [TokenTransfer](./tokentransfer.html)     | `tokenPool.id`              |                         |
+| `token_transfer_op_failed`                  | [Operation](./operation.html)             | `tokenPool.id`              | `tokenTransfer.localId` |
+| `token_approval_confirmed`                  | [TokenApproval](./tokenapproval.html)     | `tokenPool.id`              |                         |
+| `token_approval_op_failed`                  | [Operation](./operation.html)             | `tokenPool.id`              | `tokenApproval.localId` |
+| `namespace_confirmed`                       | [Namespace](./namespace.html)             | `"ff_definition"`           |                         |
+| `datatype_confirmed`                        | [Datatype](./datatype.html)               | `"ff_definition"`           |                         |
+| `identity_confirmed`<br/>`identity_updated` | [Identity](./identity.html)               | `"ff_definition"`           |                         |
+| `contract_interface_confirmed`              | [FFI](./ffi.html)                         | `"ff_definition"`           |                         |
+| `contract_api_confirmed`                    | [ContractAPI](./contractapi.html)         | `"ff_definition"`           |                         |
+| `blockchain_event_received`                 | [BlockchainEvent](./blockchainevent.html) | From listener **            |                         |
+| `blockchain_invoke_op_succeeded`            | [Operation](./operation.html)             |                             |                         |
+| `blockchain_invoke_op_failed`               | [Operation](./operation.html)             |                             |                         |
+
+> * A separate event is emitted for _each topic_ associated with a [Message](./message.html).
 
 > ** The topic for a blockchain event is inherited from the blockchain listener,
 >    allowing you to create multiple blockchain listeners that all deliver messages

docs/reference/types/_includes/identity_description.md

@@ -10,12 +10,12 @@ Root identities are registered with only a `claim` - which is a signed
 transaction from a particular blockchain account, to bind a DID with a
 `name` that is unique within the network, to that signing key.
 
-The signing key then becomes a [Verifier](./(verifier.md) for that identity.
+The signing key then becomes a [Verifier](./verifier.html) for that identity.
 Using that key the root identity can be used to register a new FireFly node
 in the network, send and receive messages, and register child identities.
 
 When child identities are registered, a `claim` using a key that is going
-to be the [Verifier](./(verifier.md) for that child identity is required.
+to be the [Verifier](./verifier.html) for that child identity is required.
 However, this is insufficient to establish that identity as a child identity
 of the parent. There must be an additional `verification` that references
 the `claim` (by UUID) using the key verifier of the parent identity.

docs/reference/types/_includes/message_description.md

@@ -18,7 +18,7 @@ The hash is a function of the header, and all of the data payloads. Calculated a
   - JSON data is serialized without whitespace to hash it.
   - The hashing algorithm is SHA-256
 
-Each node independently calculates the hash, and the hash is included in the manifest of the [Batch](./(batch.md) by the
+Each node independently calculates the hash, and the hash is included in the manifest of the [Batch](./batch.html) by the
 node that sends the message.
 Because the hash of that batch manifest is included in the blockchain transaction, a message transferred to
 a node that does not match the original message hash is rejected.
@@ -95,15 +95,15 @@ Some examples:
 
 ### Transaction type
 
-By default messages are pinned to the blockchain, within a [Batch](./(batch.md).
+By default messages are pinned to the blockchain, within a [Batch](./batch.html).
 
 For private messages, you can choose to disable this pinning by setting `header.txtype: "unpinned"`.
 
 Broadcast messages must be pinned to the blockchain.
 
 ### In-line data
 
-When sending a message you can specify the array of [Data](./(data.md) attachments in-line, as part of the same JSON payload.
+When sending a message you can specify the array of [Data](./data.html) attachments in-line, as part of the same JSON payload.
 
 For example, a minimal broadcast message could be:
 

docs/reference/types/_includes/operation_description.md

@@ -3,6 +3,6 @@ They are grouped into Transactions in order to accomplish a single logical task.
 
 The diagram below shows the different types of operation that are performed by each
 FireFly plugin type. The color coding (and numbers) map those different types of operation
-to the [Transaction](./(transaction.md) types that include those operations.
+to the [Transaction](./transaction.html) types that include those operations.
 
 [![FireFly operations by transaction type](../../images/operations_by_transaction_type.jpg)](../../images/operations_by_transaction_type.jpg)

docs/reference/types/_includes/subscription_description.md

@@ -75,12 +75,12 @@ FireFly has a simple protocol on top of WebSockets:
 1. Each time you connect/reconnect you need to tell FireFly to start
    sending you events on a particular subscription. You can do this in two
    ways (described in detail below):
-    1. Send a [WSStart](./(wsstart.md) JSON payload
+    1. Send a [WSStart](./wsstart.html) JSON payload
     2. Include a `namespace` and `name` query parameter in the URL when you
-       connect, along with query params for other fields of [WSStart](./(wsstart.md)
+       connect, along with query params for other fields of [WSStart](./wsstart.html)
 2. One you have started your subscription, each event flows from
-   the server, to your application as a JSON [Event](./(event.md) payload
-3. For each event you receive, you need to send a [WSAck](./(wsack.md) payload.
+   the server, to your application as a JSON [Event](./event.html) payload
+3. For each event you receive, you need to send a [WSAck](./wsack.html) payload.
     - Unless you specified `autoack` in step (1)
 
 > The SDK libraries for FireFly help you ensure you send the `start`

docs/reference/types/_includes/transaction_description.md

@@ -1,4 +1,4 @@
-FireFly Transactions are a grouping construct for a number of [Operations](./(operations.md) and [Events](./(events.md)
+FireFly Transactions are a grouping construct for a number of [Operations](./operation.html) and [Events](./event.html)
 that need to complete or fail as unit.
 
 > FireFly Transactions are not themselves Blockchain transactions, but in many cases there is
@@ -24,7 +24,7 @@ event as well.
 [![FireFly Transactions - Explorer View](../../images/firefly_transactions_explorer_view.png)](../../images/firefly_transactions_explorer_view.png)
 
 Each FireFly transaction has a UUID. This UUID is propagated through to all participants in a FireFly transaction.
-For example in a [Token Transfer](./(tokentransfer.md) that is coordinated with an off-chain private [Message](./(message.md),
+For example in a [Token Transfer](./tokentransfer.html) that is coordinated with an off-chain private [Message](./message.html),
 the transaction ID is propagated to all parties who are part of that transaction. So the same UUID can be used
 to find the transaction in the FireFly Explorer of any member who has access to the message.
 This is possible because hash-pinned off-chain data is associated with that on-chain transfer.

docs/reference/types/_includes/wsack_description.md

@@ -1,6 +1,6 @@
 An `ack` must be sent on a WebSocket for each event delivered to an application.
 
-> Unless `autoack` is set in the [WSStart](./(wsstart.md) payload/URL parameters to cause
+> Unless `autoack` is set in the [WSStart](./wsstart.html) payload/URL parameters to cause
 > automatic acknowledgement.
 
 Your application should specify the `id` of each event that it acknowledges.
@@ -11,5 +11,5 @@ application that has not been acknowledged is the one the `ack` is associated wi
 If multiple subscriptions are started on a WebSocket, then you need to specify the
 subscription `namespace`+`name` as part of each `ack`.
 
-If you send an acknowledgement that cannot be correlated, then a [WSError](./(wserror.md)
+If you send an acknowledgement that cannot be correlated, then a [WSError](./wserror.html)
 payload will be sent to the application.