diff --git a/specifications/catalog/catalog.protocol.md b/specifications/catalog/catalog.protocol.md index 0b44e7c..ea518ad 100644 --- a/specifications/catalog/catalog.protocol.md +++ b/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=]. diff --git a/specifications/common/common.protocol.md b/specifications/common/common.protocol.md index 46931c6..20460d7 100644 --- a/specifications/common/common.protocol.md +++ b/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. diff --git a/specifications/common/terminology.md b/specifications/common/terminology.md index 8157b8b..4ebef6f 100644 --- a/specifications/common/terminology.md +++ b/specifications/common/terminology.md @@ -48,19 +48,15 @@ Note 1 to entry: This specification convers only protocols to facilitate interop Dataspace Protocol -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. Data Transfer Protocol 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. -Message - -An instantiation of a [=Message Type=]. - Message Type -A definition of the structure of a [=Message=]. +A definition of the structure of a Message. Offer diff --git a/specifications/negotiation/contract.negotiation.protocol.md b/specifications/negotiation/contract.negotiation.protocol.md index 3236bcb..6ce307c 100644 --- a/specifications/negotiation/contract.negotiation.protocol.md +++ b/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). diff --git a/specifications/transfer/transfer.process.protocol.md b/specifications/transfer/transfer.process.protocol.md index 288743e..18c22c3 100644 --- a/specifications/transfer/transfer.process.protocol.md +++ b/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