chore: removing the message definition (#233)

removing the message definition

* removing the message definition
* removing the reference to the message definition
* changing some message type mentions to the message type definition

Author: ssteinbuss

specifications/catalog/catalog.protocol.md

@@ -3,7 +3,7 @@
 ## Introduction
 
 The [=Catalog Protocol=] defines how a [=Catalog=] is requested from a [=Catalog Service=] by a [=Consumer=] using an
-abstract [=Message=] exchange format. The concrete [=Message=] exchange wire format is defined in the binding.
+abstract Message exchange format. The concrete Message exchange wire format is defined in the binding.
 
 The [=Catalog Protocol=] reuses properties from the DCAT and ODRL vocabularies with restrictions defined in this
 specification. This is done implicitly by the use of the JSON schemas and JSON-LD-contexts that are part of the [=Dataspace Protocol=].

specifications/common/common.protocol.md

@@ -9,9 +9,9 @@ does not require authorization.
 ## Schemas & Contexts
 
 All protocol [=Messages=] are normatively defined by a [[json-schema]]. This specification also uses JSON-LD 1.1 and
-provides a JSON-LD context to serialize data structures and [=Message=] types as it facilitates extensibility. The
-JSON-LD context is designed to produce [=Message=] serializations using compaction that validate against the JSON Schema
-for the given [=Message=] type. This allows implementations to choose whether to process [=Messages=] as plain JSON or
+provides a JSON-LD context to serialize data structures and [=Message types=] as it facilitates extensibility. The
+JSON-LD context is designed to produce Message serializations using compaction that validate against the JSON Schema
+for the given [=Message type=]. This allows implementations to choose whether to process [=Messages=] as plain JSON or
 as JSON-LD and maintain interoperability between those approaches. Profiles that use JSON-LD are encouraged to provide
 similar contexts that facilitate this approach to interoperability. As this specification's JSON-LD objects are 
 `@protected`, [=Profile=] authors are advised to define their custom terms as protected to spot term redefinition early.

specifications/common/terminology.md

@@ -48,19 +48,15 @@ Note 1 to entry: This specification convers only protocols to facilitate interop
 
 <dfn>Dataspace Protocol</dfn>
 
-A set of [=Messages=] and [=Message=] sequences that enables the interaction between [=Participant Agents=] in a [=Dataspace=]. This MAY require additional concepts, which are not in the scope of the specification itself.
+A set of Messages and Message sequences that enables the interaction between [=Participant Agents=] in a [=Dataspace=]. This may require additional concepts, which are not in the scope of the specification itself.
 
 <dfn>Data Transfer Protocol</dfn>
 
 A set of rules and conventions that dictate how data is transmitted over a network by defining the format, error handling, and flow control. Examples include HTTP, FTP, MQTT, and AMQP.
 
-<dfn>Message</dfn>
-
-An instantiation of a [=Message Type=].
-
 <dfn>Message Type</dfn>
 
-A definition of the structure of a [=Message=].
+A definition of the structure of a Message.
 
 <dfn>Offer</dfn>
 

specifications/negotiation/contract.negotiation.protocol.md

@@ -6,7 +6,7 @@ A [=Contract Negotiation=] involves two parties, a [=Provider=] that offers one
 and a [=Consumer=] that requests [=Datasets=]. A [=Contract Negotiation=] is uniquely identified through an Internationalized Resource Identifier (IRI) [[rfc3987]]. Each [=Contract Negotiation=]
 requires a newly generated IRI, which MAY not be used in a [=Contract Negotiation=] after a terminal state has been reached. A [=Contract Negotiation=] progresses
 through a series of states, which are tracked by the [=Provider=] and [=Consumer=] using [=Messages=]. A [=Contract Negotiation=] transitions to a
-state in response to an acknowledged [=Message=] from the counter-party. Both parties have the same state of the [=Contract Negotiation=]. In case
+state in response to an acknowledged Message from the counter-party. Both parties have the same state of the [=Contract Negotiation=]. In case
 the states differ, the [=Contract Negotiation=] MUST be terminated and a new [=Contract Negotiation=] MAY be initiated.
 
 ### States {#contract-negotiation-states}
@@ -21,9 +21,9 @@ The [=Contract Negotiation=] states are:
   the [=Consumer=] has sent an ACK response.
 - **VERIFIED**: The [=Consumer=] has sent an [=Agreement=] verification to the [=Provider=] and the [=Provider=] has
   sent an ACK response.
-- **FINALIZED**: The [=Provider=] has sent a finalization [=Message=] including his own [=Agreement=] verification to
+- **FINALIZED**: The [=Provider=] has sent a finalization Message including his own [=Agreement=] verification to
   the [=Consumer=] and the [=Consumer=] has sent an ACK response. Data is now available to the [=Consumer=].
-- **TERMINATED**: The [=Provider=] or [=Consumer=] has placed the [=Contract Negotiation=] in a terminated state. A termination [=Message=] has
+- **TERMINATED**: The [=Provider=] or [=Consumer=] has placed the [=Contract Negotiation=] in a terminated state. A termination Message has
   been sent by either of the [=Participants=] and the other has sent an ACK response. This is a terminal state.
 
 ### State Machine
@@ -32,12 +32,12 @@ The [=Contract Negotiation=] state machine is represented in the following diagr
 
 !["Contract Negotiation State Machine"](figures/contract.negotiation.state.machine.png "Contract Negotiation State Machine")
 
-Transitions marked with `C` indicate a [=Message=] sent by the [=Consumer=], transitions marked with `P` indicate
-a [=Provider=] [=Message=]. Terminal states are final; the state machine MUST NOT transition to another state. A new [=Contract Negotiation=] MAY be initiated if, for instance, the [=Contract Negotiation=] entered the `TERMINATED` state due to a network issue.
+Transitions marked with `C` indicate a Message sent by the [=Consumer=], transitions marked with `P` indicate
+a [=Provider=] Message. Terminal states are final; the state machine MUST NOT transition to another state. A new [=Contract Negotiation=] MAY be initiated if, for instance, the [=Contract Negotiation=] entered the `TERMINATED` state due to a network issue.
 
 ## Message Types
 
-The [=Contract Negotiation=] state machine is transitioned upon receipt and acknowledgement of a [=Message=]. This section details those [=Messages=] as abstract [=Message Types=].
+The [=Contract Negotiation=] state machine is transitioned upon receipt and acknowledgement of a Message. This section details those [=Messages=] as abstract [=Message Types=].
 
 - Concrete wire formats are defined by the protocol binding,
   e.g., [Contract Negotiation HTTPS Binding](#contract-negotiation-https-binding).

specifications/transfer/transfer.process.protocol.md

@@ -5,7 +5,7 @@
 A [=Transfer Process=] involves two parties, a [=Provider=] that offers one or more [=Datasets=] along with
 a [=Policy=] and a [=Consumer=] that requests [=Datasets=]. A [=Transfer Process=] progresses through a series of states, which are
 controlled by the [=Provider=] and [=Consumer=] using [=Messages=]. A [=Transfer Process=] transitions to another state as a result of an
-exchanged [=Message=].
+exchanged Message.
 
 ### Prerequisites