Merge pull request #484 from duglin/data

tweak how we talk about data and datacontentencoding

amqp-transport-binding.md

@@ -22,7 +22,7 @@ This document is a working draft.
 2. [Use of CloudEvents Attributes](#2-use-of-cloudevents-attributes)
 
 - 2.1. [datacontenttype Attribute](#21-datacontenttype-attribute)
-- 2.2. [data Attribute](#22-data-attribute)
+- 2.2. [data](#22-data)
 
 3. [AMQP Message Mapping](#3-amqp-message-mapping)
 
@@ -70,7 +70,7 @@ In the _structured_ content mode, event metadata attributes and event data are
 placed into the AMQP message's [application data][data] section using an
 [event format](#14-event-formats).
 
-In the _binary_ content mode, the value of the event `data` attribute is placed
+In the _binary_ content mode, the value of the event `data` is placed
 into the AMQP message's [application data][data] section as-is, with the
 `datacontenttype` attribute value declaring its media type; all other event
 attributes are mapped to the AMQP [application-properties][app-properties]
@@ -108,18 +108,18 @@ event metadata. Any mention of event attributes other than `datacontenttype` and
 The `datacontenttype` attribute is assumed to contain a [RFC2046][rfc2046]
 compliant media-type expression.
 
-### 2.2. data Attribute
+### 2.2. data
 
-The `data` attribute is assumed to contain opaque application data that is
+`data` is assumed to contain opaque application data that is
 encoded as declared by the `datacontenttype` attribute.
 
 An application is free to hold the information in any in-memory representation
 of its choosing, but as the value is transposed into AMQP as defined in this
-specification, the assumption is that the `data` attribute value is made
+specification, the assumption is that the `data` value is made
 available as a sequence of bytes.
 
 For instance, if the declared `datacontenttype` is
-`application/json;charset=utf-8`, the expectation is that the `data` attribute
+`application/json;charset=utf-8`, the expectation is that the `data`
 value is made available as [UTF-8][rfc3629] encoded JSON text for use in AMQP.
 
 ## 3. AMQP Message Mapping
@@ -151,7 +151,7 @@ directly to the CloudEvents `datacontenttype` attribute.
 
 #### 3.1.2. Event Data Encoding
 
-The [`data` attribute](#22-data-attribute) byte-sequence is used as the AMQP
+The [`data`](#22-data) byte-sequence is used as the AMQP
 [application-data][data] section.
 
 #### 3.1.3. Metadata Headers
@@ -236,8 +236,8 @@ content-type: application/cloudevents+json; charset=UTF-8
 
 #### 3.2.2. Event Data Encoding
 
-The chosen [event format](#14-event-formats) defines how all attributes,
-including the `data` attribute, are represented.
+The chosen [event format](#14-event-formats) defines how all attributes
+and `data` are represented.
 
 The event metadata and data is then rendered in accordance with the event format
 specification and the resulting data becomes the AMQP application [data][data]

extensions/dataref.md

@@ -2,13 +2,13 @@
 
 As defined by the term [Data](../spec.md#data), CloudEvents MAY include
 domain-specific information about the occurrence. When present, this information
-will be encapsulated within the `data` attribute.
+will be encapsulated within `data`.
 The `dataref` attribute MAY be used to reference another location where this
 information is stored. The information, whether accessed via `data` or `dataref`
 MUST be identical.
 
-Both the `data` and `dataref` attribute MAY exist at the same time. A middleware
-MAY drop the `data` attribute when the `dataref` attribute exists, it MAY add
+Both `data` and the `dataref` attribute MAY exist at the same time. A middleware
+MAY drop `data` when the `dataref` attribute exists, it MAY add
 the `dataref` attribute and drop the `data` attribute, or it MAY add the `data`
 attribute by using the `dataref` attribute.
 
@@ -24,7 +24,7 @@ attribute by using the `dataref` attribute.
   of purposes, including:
 
   * If the [Data](../spec.md#data) is too large to be included in the message,
-    the `data` attribute is not present, and the consumer can retrieve it using
+    the `data` is not present, and the consumer can retrieve it using
     this attribute.
   * If the consumer wants to verify that the [Data](../spec.md#data) has not
     been tampered with, it can retrieve it from a trusted source using this

http-transport-binding.md

@@ -22,7 +22,7 @@ This document is a working draft.
 2. [Use of CloudEvents Attributes](#2-use-of-cloudevents-attributes)
 
 - 2.1. [datacontenttype Attribute](#21-datacontenttype-attribute)
-- 2.2. [data Attribute](#22-data-attribute)
+- 2.2. [data](#22-data)
 
 3. [HTTP Message Mapping](#3-http-message-mapping)
 
@@ -69,7 +69,7 @@ This specification defines three content modes for transferring events:
 _binary_, _structured_ and _batched_. Every compliant implementation SHOULD
 support the _structured_ and _binary_ modes.
 
-In the _binary_ content mode, the value of the event `data` attribute is placed
+In the _binary_ content mode, the value of the event `data` is placed
 into the HTTP request or response body as-is, with the `datacontenttype`
 attribute value declaring its media type; all other event attributes are mapped
 to HTTP headers.
@@ -118,18 +118,18 @@ event metadata. Any mention of event attributes other than `datacontenttype` and
 The `datacontenttype` attribute is assumed to contain a [RFC2046][rfc2046]
 compliant media-type expression.
 
-### 2.2. data Attribute
+### 2.2. data
 
-The `data` attribute is assumed to contain opaque application data that is
+`data` is assumed to contain opaque application data that is
 encoded as declared by the `datacontenttype` attribute.
 
 An application is free to hold the information in any in-memory representation
 of its choosing, but as the value is transposed into HTTP as defined in this
-specification, the assumption is that the `data` attribute value is made
+specification, the assumption is that the `data` value is made
 available as a sequence of bytes.
 
 For instance, if the declared `datacontenttype` is
-`application/json;charset=utf-8`, the expectation is that the `data` attribute
+`application/json;charset=utf-8`, the expectation is that the `data`
 value is made available as [UTF-8][rfc3629] encoded JSON text to HTTP.
 
 ## 3. HTTP Message Mapping
@@ -165,7 +165,7 @@ CloudEvents `datacontenttype` attribute.
 
 #### 3.1.2. Event Data Encoding
 
-The [`data` attribute](#22-data-attribute) byte-sequence is used as the HTTP
+The [`data`](#22-data) byte-sequence is used as the HTTP
 message body.
 
 #### 3.1.3. Metadata Headers
@@ -281,7 +281,7 @@ Content-Type: application/cloudevents+json; charset=UTF-8
 #### 3.2.2. Event Data Encoding
 
 The chosen [event format](#14-event-formats) defines how all attributes,
-including the `data` attribute, are represented.
+and `data`, are represented.
 
 The event metadata and data is then rendered in accordance with the event format
 specification and the resulting data becomes the HTTP message body.
@@ -361,7 +361,7 @@ Content-Type: application/cloudevents-batch+json; charset=UTF-8
 #### 3.3.2. Event Data Encoding
 
 The chosen [event format](#14-event-formats) defines how a batch of events and
-all event attributes, including the `data` attribute, are represented.
+all event attributes, and `data`, are represented.
 
 The batch of events is then rendered in accordance with the event format
 specification and the resulting data becomes the HTTP message body.

json-format.md

@@ -89,18 +89,12 @@ inference using the rules from the mapping table, whereby the only potentially
 ambiguous JSON data type is `string`. The value is compatible with the
 respective CloudEvents type when the mapping rules are fulfilled.
 
-### 2.3. Mapping Any-typed Attributes
+### 2.3. Mapping Data
 
-The CloudEvents `data` attribute is `Any`-typed, meaning that it holds a value
-of any valid type. `Map` entry values are also `Any` typed.
-
-If an implementation determines that the actual type of an `Any` is a `String`,
+If an implementation determines that the actual type of `data` is a `String`,
 the value MUST be represented as [JSON string][json-string] expression; for
 `Binary`, the value MUST represented as [JSON string][json-string] expression
-containing the [Base64][base64] encoded binary value; for `Map`, the value MUST
-be represented as a [JSON object][json-object] expression, whereby the index
-fields become member names and the associated values become the respective
-member's value.
+containing the [Base64][base64] encoded binary value.
 
 ### 2.4. Examples
 
@@ -134,23 +128,23 @@ become members of the JSON object, with the respective JSON object member name
 matching the attribute name, and the member's type and value being mapped using
 the [type system mapping](#22-type-system-mapping).
 
-### 3.1. Special Handling of the "data" Attribute
+### 3.1. Special Handling of "data"
 
-The mapping of the `Any`-typed `data` attribute follows the rules laid out in
-[Section 2.3.](#23-mapping-any-typed-attributes), with two additional rules:
+The mapping of `data` follows the rules laid out in
+[Section 2.3.](#23-mapping-data), with two additional rules:
 
-First, if an implementation determines that the type of the `data` attribute is
+First, if an implementation determines that the type of `data` is
 `Binary` or `String`, it MUST inspect the `datacontenttype` attribute to
 determine whether it is indicated that the data value contains JSON data.
 
 If the `datacontenttype` value is either ["application/json"][rfc4627] or any
 media type with a [structured +json suffix][rfc6839], the implementation MUST
-translate the `data` attribute value into a [JSON value][json-value], and set
+translate the `data` value into a [JSON value][json-value], and set
 the `data` attribute of the envelope JSON object to this JSON value.
 
 If the `datacontenttype` value does not follow the [structured +json
 suffix][rfc6839] but is known to use JSON encoding, the implementation MUST
-translate the `data` attribute value into a [JSON value][json-value], and set
+translate the `data` value into a [JSON value][json-value], and set
 the `data` attribute of the envelope JSON object to this JSON value. Its typical
 examples are, but not limited to, `text/json`,
 [`application/json-seq`][json-seq] and
@@ -161,7 +155,7 @@ the [type-system mapping](#22-type-system-mapping), the resulting `data` member
 [JSON value][json-value] is unrestricted, and MAY also contain numeric and
 logical JSON types.
 
-Second, whether a Base64-encoded string in the data attribute is treated as
+Second, whether a Base64-encoded string in `data` is treated as
 `Binary` or as a `String` is also determined by the `datacontenttype` value. If
 the `datacontenttype` media type is known to contain text, the data attribute
 value is not further interpreted and treated as a text string. Otherwise, it is
@@ -206,7 +200,7 @@ Example event with `Binary`-valued data
 ```
 
 Example event with JSON data for the "data" member, either derived from a `Map`
-or [JSON data](#31-special-handling-of-the-data-attribute) data:
+or [JSON data](#31-special-handling-of-data) data:
 
 ```JSON
 {

kafka-transport-binding.md

@@ -18,7 +18,7 @@ This document is a working draft.
 - 1.4. [Event Formats](#14-event-formats)
 - 1.5. [Security](#15-security)
 2. [Use of CloudEvents Attributes](#2-use-of-cloudevents-attributes)
-- 2.1. [data Attribute](#21-data-attribute)
+- 2.1. [data](#21-data)
 3. [Kafka Message Mapping](#3-kafka-message-mapping)
 - 3.1. [Key Attribute](#31-key-attribute)
 - 3.2. [Binary Content Mode](#32-binary-content-mode)
@@ -52,7 +52,7 @@ The specification defines two content modes for transferring events:
 The *binary* mode *only* applies to Kafka 0.11.0.0 and above, because Kafka
 0.10.x.x and below lack support for message level headers.
 
-In the *binary* content mode, the value of the event `data` attribute MUST be
+In the *binary* content mode, the value of the event `data` MUST be
 placed into the Kafka message's value section as-is, with the
 `ce_datacontenttype` header value declaring its media type; all other
 event attributes MUST be mapped to the Kafka message's 
@@ -80,17 +80,17 @@ mandate specific existing features to be used.
 This specification does not further define any of the [CloudEvents][CE] event
 attributes.
 
-### 2.1. data Attribute
+### 2.1. data
 
-The `data` attribute is assumed to contain opaque application data that is
+`data` is assumed to contain opaque application data that is
 encoded as declared by the `datacontenttype` attribute.
 
 An application is free to hold the information in any in-memory representation
 of its choosing, but as the value is transposed into Kafka as defined in this
 specification, core Kafka provides data available as a sequence of bytes.
 
 For instance, if the declared `datacontenttype` is
-`application/json;charset=utf-8`, the expectation is that the `data` attribute
+`application/json;charset=utf-8`, the expectation is that the `data`
 value is made available as [UTF-8][RFC3629] encoded JSON text.
 
 ## 3. Kafka Message Mapping
@@ -131,7 +131,7 @@ mapped directly to the CloudEvents `datacontenttype` attribute.
 
 #### 3.2.2. Event Data Encoding
 
-The [`data` attribute](#21-data-attribute) byte-sequence MUST be used as the
+The [`data`](#21-data) byte-sequence MUST be used as the
 value of the Kafka message.
 
 #### 3.2.3. Metadata Headers
@@ -214,7 +214,7 @@ content-type: application/cloudevents+json; charset=UTF-8
 #### 3.3.2. Event Data Encoding
 
 The chosen [event format](#14-event-formats) defines how all attributes,
-including the `data` attribute, are represented.
+and `data`, are represented.
 
 The event metadata and data are then rendered in accordance with the [event
 format](#14-event-formats) specification and the resulting data becomes the

mqtt-transport-binding.md

@@ -23,7 +23,7 @@ This document is a working draft.
 2. [Use of CloudEvents Attributes](#2-use-of-cloudevents-attributes)
 
 - 2.1. [datacontenttype Attribute](#21-datacontenttype-attribute)
-- 2.2. [data Attribute](#22-data-attribute)
+- 2.2. [data](#22-data)
 
 3. [MQTT PUBLISH Message Mapping](#3-mqtt-publish-message-mapping)
 
@@ -63,7 +63,7 @@ In the _structured_ content mode, event metadata attributes and event data are
 placed into the MQTT PUBLISH message payload section using an
 [event format](#14-event-formats).
 
-In the _binary_ content mode, the value of the event `data` attribute is placed
+In the _binary_ content mode, the value of the event `data` is placed
 into the MQTT PUBLISH message's payload section as-is, with the
 `datacontenttype` attribute value declaring its media type; all other event
 attributes are mapped to the MQTT PUBLISH message's [properties
@@ -102,18 +102,18 @@ event metadata. Any mention of event attributes other than `datacontenttype` and
 The `datacontenttype` attribute is assumed to contain a [RFC2046][rfc2046]
 compliant media-type expression.
 
-### 2.2. data Attribute
+### 2.2. data
 
-The `data` attribute is assumed to contain opaque application data that is
+`data` is assumed to contain opaque application data that is
 encoded as declared by the `datacontenttype` attribute.
 
 An application is free to hold the information in any in-memory representation
 of its choosing, but as the value is transposed into MQTT as defined in this
-specification, the assumption is that the `data` attribute value is made
+specification, the assumption is that the `data` value is made
 available as a sequence of bytes.
 
 For instance, if the declared `datacontenttype` is
-`application/json;charset=utf-8`, the expectation is that the `data` attribute
+`application/json;charset=utf-8`, the expectation is that the `data`
 value is made available as [UTF-8][rfc3629] encoded JSON text for use in MQTT.
 
 ## 3. MQTT PUBLISH Message Mapping
@@ -149,7 +149,7 @@ CloudEvents `datacontenttype` attribute.
 
 #### 3.1.2. Event Data Encoding
 
-The [`data` attribute](#22-data-attribute) byte-sequence MUST be used as the
+The [`data`](#22-data) byte-sequence MUST be used as the
 payload of the MQTT PUBLISH message.
 
 #### 3.1.3. Metadata Headers
@@ -237,7 +237,7 @@ content-type: application/cloudevents+json; charset=utf-8
 #### 3.2.2. Event Data Encoding
 
 The chosen [event format](#14-event-formats) defines how all attributes,
-including the `data` attribute, are represented.
+and `data`, are represented.
 
 The event metadata and data MUST then be rendered in accordance with the event
 format specification and the resulting data becomes the MQTT PUBLISH payload.

nats-transport-binding.md

@@ -22,7 +22,7 @@ This document is a working draft.
 2. [Use of CloudEvents Attributes](#2-use-of-cloudevents-attributes)
 
 - 2.1. [datacontenttype Attribute](#21-datacontenttype-attribute)
-- 2.2. [data Attribute](#22-data-attribute)
+- 2.2. [data](#22-data)
 
 3. [NATS Message Mapping](#3-nats-message-mapping)
 
@@ -84,17 +84,17 @@ attributes.
 The `datacontenttype` attribute is assumed to contain a media-type expression
 compliant with [RFC2046][rfc2046].
 
-### 2.2. data Attribute
+### 2.2. data
 
-The `data` attribute is assumed to contain opaque application data that is
+`data` is assumed to contain opaque application data that is
 encoded as declared by the `datacontenttype` attribute.
 
 An application is free to hold the information in any in-memory representation
 of its choosing, but as the value is transposed into NATS as defined in this
 specification, core NATS provides data available as a sequence of bytes.
 
 For instance, if the declared `datacontenttype` is
-`application/json;charset=utf-8`, the expectation is that the `data` attribute
+`application/json;charset=utf-8`, the expectation is that the `data`
 value is made available as [UTF-8][rfc3629] encoded JSON text.
 
 ## 3. NATS Message Mapping

primer.md

@@ -112,7 +112,7 @@ might mean that some of the application data of the event itself might be
 duplicated as part of the CloudEvent's set of attributes, this is to be done
 solely for the purpose of proper delivery, and processing, of the message. Data
 that is not intended for that purpose should instead be placed within the event
-(the `data` attribute) itself.
+(`data`) itself.
 
 Additionally, it is assumed that the metadata needed by the transport layer
 to deliver the message to the target system is handled entirely by the
@@ -292,7 +292,7 @@ metadata that needs to be included to help ensure proper routing and processing
 of the CloudEvent. Additional metadata for other purposes, that is related to
 the event itself and not needed in the transportation or processing of the
 CloudEvent, should instead be placed within the proper extensibility points of
-the event (the `data` attribute) itself.
+the event (`data`) itself.
 
 Extension attributes should be kept minimal to ensure the CloudEvent can be
 properly serialized and transported. For example, the Event producers should