Remove Map from allowed Context Attribute types #467

evankanderson · 2019-06-24T16:11:50Z

Per discussion in #460 and #456, it's not clear that Map and Any types in Context Attributes are worth the trouble:

(me)

Map values are one of the more complex areas of the spec, and the only one
which does not seem to be used in the core or extensions. Furthermore, it
sounds like several other ecosystems (HTTP and AMQP) don't support them,
and the AMQP decision was guided by careful consideration.

This is not quite correct, because Map and Any are used by the data attribute in core (and hence this PR does not remove those types entirely)

It's not clear that context attributes needed for routing or other middleware decisions benefit from this flexibility (see also this thread), and the possibility of Any types as the value in a Map adds a lot of complexity to the encoding.

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>

…we-dont-need-maps

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>

duglin · 2019-06-25T01:56:23Z

http-transport-binding.md


 Two of the event attributes, `datacontenttype` and `data` are handled specially
 and mapped onto HTTP constructs, all other attributes are transferred as
-metadata without further interpretation.
+metadata without further interpretation (except that extensions may define


jroper · 2019-06-25T03:51:33Z

Related to this is #457, where data is redefined to have no specified type, but instead is required to have a Binary encoding. If that change gets merged, both Any and Map as defined in this PR can be completely removed, since data doesn't use them. This means this PR could rename Any-context back to Any.

duglin · 2019-06-27T10:54:19Z

spec.md

@@ -194,6 +195,11 @@ as a string.
  `String`, `Binary`, `Map`, `URI-reference` or `Timestamp`. The type system is
  intentionally abstract, and therefore it is left to implementations how to
  represent the `Any` type.
+- `Any-context` - A variant type which can take the shapes allowed in a context


I'm not sure I understand the purpose or value of this. If it's really only for extensions, and we treat unknown extensions as strings, why do we need this?

I would leave Any untouched. Stating that the Map type can't be used for context attributes is sufficient. Any is not a submarine through which you can smuggle Map undetected.

I was attempting to define the types additively (i.e. without any special-case rules)

I'd somewhat prefer a set of ABNF productions, though our use of an abstract type system makes that harder:

CloudEvent = "{" Attributes ["," Body-Attribute] "}" Attributes = Attribute *( "," Attribute ) Attribute = Key "=" Attribute-Value Key = 1*20( "a"-"z" / "0"-"9" ) Attribute-Value = Integer / String / Binary / URI-reference / Timestamp Data-Attribute = "data" "=" Any Any = ... Integer = *DIGIT String = ...

The current language, while serviceable, seems like it sometimes leads to confusion: for example, is "" a valid key in a Map?

I'll switch this back for now, but I think it would be clearer to have a different name.

Maybe Context-Value?

duglin · 2019-06-27T17:46:26Z

We discussed this on today's call. I believe there was general agreement that there's an issue to solve, but it wasn't clear how to proceed. There were 4 options mentioned:
1 - do nothing, leave it as-is
2 - restrict Maps to just one level (so no nesting of Maps)
3 - remove Maps as a type
4 - adopt this PR

My interpretation of what was said on the call : there seemed to be a lot of interest in dropping Maps entirely, but some people did worry that not allowing for structured extensions would limit things too much or end up with people inventing their own way to represent maps via encoding them as strings or other types. And then we might have an interop problem around decoding those custom things since there is no single way to do it. Please correct me if I got this wrong.

Please chime in on this one as it's kind of a biggie to solve prior to v1.0

clemensv

Using Any is fine if the concrete type used is not a map.

The only thing I would add with this PR is this text:

Context and extension attributes MUST NOT have Map values, even when their type is Any.

clemensv · 2019-07-01T14:15:29Z

spec.md

@@ -210,6 +216,17 @@ and the event data will be materialized. For example, in the case of a JSON
 serialization, the context attributes and the event data might both appear
 within the same JSON object.

+Context attributes MUST be one of the following types:


I believe the half sentence in line 227 is sufficient for this PR.

Map values MUST NOT be used in context attributes, including in extension attributes.

Done. I'm slightly uncomfortable with the formulation, but the result is clear if you read the whole spec:

The value of a context attribute is Integer, String, Binary, Map, URI-reference, Timestamp, or Any, except that it can't be Any or Map.

If we accept some form of #457, we can completely remove Map, and the sentence simplifies to:

The value of a context attribute is Integer, String, Binary, Map, URI-reference, Timestamp, or Any.

clemensv · 2019-07-01T14:16:05Z

spec.md

@@ -182,7 +182,8 @@ as a string.
 - `Binary` - Sequence of bytes.
  - String encoding: Base64 encoding per
    [RFC4648](https://tools.ietf.org/html/rfc4648).
- `Map` - `String`-indexed dictionary of `Any`-typed values.
+- `Map` - `String`-indexed dictionary of `Any`-typed values. Only valid in the


It's sufficient to say this only in one place normatively.

I'm concerned about confusion between line 150 and later, but I'll remove if this seems clear to everyone.

The following abstract data types are available for use in attributes.

clemensv · 2019-07-01T14:17:34Z

spec.md

@@ -194,6 +195,11 @@ as a string.
  `String`, `Binary`, `Map`, `URI-reference` or `Timestamp`. The type system is
  intentionally abstract, and therefore it is left to implementations how to
  represent the `Any` type.
+- `Any-context` - A variant type which can take the shapes allowed in a context


I would leave Any untouched. Stating that the Map type can't be used for context attributes is sufficient. Any is not a submarine through which you can smuggle Map undetected.

clemensv · 2019-07-01T14:18:31Z

mqtt-transport-binding.md

@@ -176,7 +176,8 @@ in the MQTT PUBLISH message.
 ##### 3.1.3.2 User Property Values

 The value for each MQTT PUBLISH User Property MUST be constructed from the
-respective CloudEvents attribute type's canonical string representation.
+respective CloudEvents attribute type's canonical string representation in the
+[JSON][json-format] string encoding.


We define the canonical representations here. We've decoupled them from JSON now.

Thanks, updated the link to the type system

evankanderson

If we accept some form of #457 which removes data from the CloudEvents type system, I think we could remove Map entirely.

I'm happy to wait until 457 is resolved to update this and hopefully remove Map altogether. If we can't remove Map, I think it would be clearer to define Context-Value and Data-Value types separately, and remove the Any type, rather than doing some sort of strikethrough on what's allowed in a context attribute.

evankanderson · 2019-07-02T17:40:35Z

spec.md

@@ -194,6 +195,11 @@ as a string.
  `String`, `Binary`, `Map`, `URI-reference` or `Timestamp`. The type system is
  intentionally abstract, and therefore it is left to implementations how to
  represent the `Any` type.
+- `Any-context` - A variant type which can take the shapes allowed in a context


I was attempting to define the types additively (i.e. without any special-case rules)

I'd somewhat prefer a set of ABNF productions, though our use of an abstract type system makes that harder:

CloudEvent = "{" Attributes ["," Body-Attribute] "}" Attributes = Attribute *( "," Attribute ) Attribute = Key "=" Attribute-Value Key = 1*20( "a"-"z" / "0"-"9" ) Attribute-Value = Integer / String / Binary / URI-reference / Timestamp Data-Attribute = "data" "=" Any Any = ... Integer = *DIGIT String = ...

The current language, while serviceable, seems like it sometimes leads to confusion: for example, is "" a valid key in a Map?

evankanderson · 2019-07-02T17:43:47Z

spec.md

@@ -194,6 +195,11 @@ as a string.
  `String`, `Binary`, `Map`, `URI-reference` or `Timestamp`. The type system is
  intentionally abstract, and therefore it is left to implementations how to
  represent the `Any` type.
+- `Any-context` - A variant type which can take the shapes allowed in a context


I'll switch this back for now, but I think it would be clearer to have a different name.

Maybe Context-Value?

evankanderson · 2019-07-02T17:56:08Z

http-transport-binding.md


 Two of the event attributes, `datacontenttype` and `data` are handled specially
 and mapped onto HTTP constructs, all other attributes are transferred as
-metadata without further interpretation.
+metadata without further interpretation (except that extensions may define


evankanderson · 2019-07-02T18:41:45Z

mqtt-transport-binding.md

@@ -176,7 +176,8 @@ in the MQTT PUBLISH message.
 ##### 3.1.3.2 User Property Values

 The value for each MQTT PUBLISH User Property MUST be constructed from the
-respective CloudEvents attribute type's canonical string representation.
+respective CloudEvents attribute type's canonical string representation in the
+[JSON][json-format] string encoding.


Thanks, updated the link to the type system

evankanderson · 2019-07-02T18:43:42Z

spec.md

@@ -182,7 +182,8 @@ as a string.
 - `Binary` - Sequence of bytes.
  - String encoding: Base64 encoding per
    [RFC4648](https://tools.ietf.org/html/rfc4648).
- `Map` - `String`-indexed dictionary of `Any`-typed values.
+- `Map` - `String`-indexed dictionary of `Any`-typed values. Only valid in the


I'm concerned about confusion between line 150 and later, but I'll remove if this seems clear to everyone.

The following abstract data types are available for use in attributes.

evankanderson · 2019-07-02T18:47:33Z

spec.md

@@ -210,6 +216,17 @@ and the event data will be materialized. For example, in the case of a JSON
 serialization, the context attributes and the event data might both appear
 within the same JSON object.

+Context attributes MUST be one of the following types:


Done. I'm slightly uncomfortable with the formulation, but the result is clear if you read the whole spec:

The value of a context attribute is Integer, String, Binary, Map, URI-reference, Timestamp, or Any, except that it can't be Any or Map.

If we accept some form of #457, we can completely remove Map, and the sentence simplifies to:

The value of a context attribute is Integer, String, Binary, Map, URI-reference, Timestamp, or Any.

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>

duglin · 2019-07-03T02:15:22Z

spec.md

@@ -211,6 +211,9 @@ and the event data will be materialized. For example, in the case of a JSON
 serialization, the context attributes and the event data might both appear
 within the same JSON object.

+`Any` and `Map` values MUST NOT be used in context attributes, including in
+extension attributes.


I like this version of the PR better - it feels less confusing to me. One thing I think we need to do is expand a bit of this sentence. Normally I would say we should do it in the Primer because the text in the spec should be obvious and the Primer is just for a more in-depth discussion, but in this case there's no indication at all as to why we're making this rule.

Do we need to say "Any" or can "Map" alone cover it? I wonder if someone will read it as: Any == one of int, string, etc... and therefore I can't use any of those. Or maybe: Values of type Map, either directly or via the Any type, MUST NOT be used in context attributes, including in extension attributes.

ping @evankanderson

Done.

FWIW, I find this construction more complicated than defining a separate type, because now we can't say elsewhere in the spec "Unknown extension attributes should be assumed to be of type Any" (for example) without including a reference to this clarification.

JemDay · 2019-07-10T18:58:17Z

General Comment :

I understand the drive for this change but would ask that we consider retaining some model that allows for extensions to be represented as a map in some constrained form; i believe there is value in keeping them grouped together.

I would propose that an extension be defined as a "string indexed dictionary of string typed values" (or something similar) to prevent the map-of-maps situation.

Doing this means that existing transport bindings for extensions continue to work unchanged, and the spec.json change would be very subtle:

"extensions": {
      "type": "object",
      "additionalProperties" : {
		"type" : "string"
      }
 },

duglin · 2019-07-10T23:29:04Z

I have mixed feeling about this, but one of the things that I keep thinking about is when someone (maybe @clemensv) mentioned that just about any serialization of maps in binary format (e.g. as http headers) will result in a really non-trivial mechanism to do filtering over that data. And when I combine that with the idea that CloudEvents metadata should not really be used to carry business logic (that's what data is for), and people will want to do quick filtering/routing on the CloudEvent metadata, it pushes me more towards the idea that it may not be a bad thing to force people into a model of limiting what they put into CloudEvents metadata. Which means having Maps could be viewed as encouraging more complex and large pieces of data.

And I guess, it's worth reminding people that just because a piece of data isn't part of the CloudEvents properties doesn't mean that it can't still be used for filter/routing... people will just need to do something like data.mymap["name"]="Jeff" instead of ce-mymap["name"]="Jeff".

Of course I also once suggested that everything be strings... so what do I know :-)
(although, that's almost where we are now)

…ap` is allowed. Signed-off-by: Evan Anderson <argent@google.com>

evankanderson · 2019-07-11T16:42:37Z

Observation from a number of transports:

HTTP has string-string header maps, but no support for nested structure.
AMQP has string-<type> headers, but <type> cannot be a nested structure.
Google PubSub has string-string properties.
MQTT has string-string user properties
SQS supports a max of 10 string-<type> attributes, where type is Int, Binary, String
Kafka has string-byte headers.

JemDay · 2019-07-12T21:57:48Z

Apologies if this is a bit rambling, hopefully you can see what i'm driving at:

My understanding of how extensions that allow for mutiple attributes would be represented (currently and with my proposal)

Example using the sequence and partioning extension along with a company (Bobs Bait Shop - BBS) private internal extension.

HTTP, Structured, JSON "data"

Content-Type : application/cloudevents+json
Content-Length : nnnn

{
    "specversion" : "0.5",
    "type" : "org.jem.example",
    "time" : "2019-07-12T20:10:00Z",
    "id" : "aaaa-bbbb-cccc",
    "extensions" : {
        "sequence" : {
            "sequence" : "99",
            "sequencetype" : "Integer"
        },
        "bbs" : {
            "ctx" : "dnflkdsnflksdnflkdnf",
            "correlation" : "666-yyyy-aaaa"
        },
        partionkey : "P1"
    }
    "data" : {
         "quote" : "Now is the winter of our discount tents"
    }
}

HTTP, Binary, JSON data

ce-specversion : 0.5
ce-type : org.jem.example
ce-time : 2019-07-12T20:10:00Z
ce-id : aaaa-bbbb-cccc
ce-sequence-sequence : 99
ce-sequence-sequencetype : Integer
ce-bbs-ctx : dnflkdsnflksdnflkdnf
ce-bbs-correlation : 666-yyyy-aaaa
ce-partionkey : P1
Content-Type: application/json
Content-Length : nnn

{
    "quote" : "Now is the winter of our discount tents"
}

Having sketched this out, and assuming i'm correct, then i believe my proposal has legs. :-)

Without some formal namespace/grouping everything gets flattened (in both modes)...

{
    "specversion" : "0.5",
    "type" : "org.jem.example",
    "time" : "2019-07-12T20:10:00Z",
    "id" : "aaaa-bbbb-cccc",
    "sequence" : "99",
    "sequencetype" : Integer",
    "ctx" : "dnflkdsnflksdnflkdnf",
    "correlation" : "666-yyyy-aaaa",
    "partionkey" : "P1",
    "data" : {
         "quote" : "Now is the winter of our discount tents"
    }
}

As an SDK provider i can no longer say to the application code "here are all the attributes of Bobs-Bait-Shop custom extension".

duglin · 2019-07-12T22:26:18Z

Actually, since we don't put extensions into a bag it would be:
HTTP, Structured, JSON "data"

Content-Type : application/cloudevents+json
Content-Length : nnnn

{
    "specversion" : "0.5",
    "type" : "org.jem.example",
    "time" : "2019-07-12T20:10:00Z",
    "id" : "aaaa-bbbb-cccc",
    "sequence" : {
        "sequence" : "99",
        "sequencetype" : "Integer"
    },
    "bbs" : {
        "ctx" : "dnflkdsnflksdnflkdnf",
        "correlation" : "666-yyyy-aaaa"
    },
    partionkey : "P1"
    "data" : {
         "quote" : "Now is the winter of our discount tents"
    }
}

The Binary version looks right.
However, if we did ban maps I think the structured version would be:

{
    "specversion" : "0.5",
    "type" : "org.jem.example",
    "time" : "2019-07-12T20:10:00Z",
    "id" : "aaaa-bbbb-cccc",
    "sequencesequence" : "99",
    "sequencesequencetype" : Integer",
    "bbsctx" : "dnflkdsnflksdnflkdnf",
    "bbscorrelation" : "666-yyyy-aaaa",
    "partionkey" : "P1",
    "data" : {
         "quote" : "Now is the winter of our discount tents"
    }
}

I would question the choice of using a prefix of "sequence" and a property of "sequence" instead of the first being a bit more descriptive (or just prefixing those two sequence ones at all), but it does work in the sense that you can just tell people to look for all properties that start with "sequence" or "bbs".

JemDay · 2019-07-12T22:41:15Z

Hmmm .. according to the spec.json file we do put extensions into a bag ;-)

duglin · 2019-07-12T22:48:10Z

LOL well that's a bug - good catch! PR coming....

duglin · 2019-07-12T22:55:02Z

@JemDay #472

duglin · 2019-07-15T01:02:21Z

@evankanderson I think this line: https://github.com/cloudevents/spec/pull/467/files#diff-958e7270f96f5407d7d980f500805b1bR422 might need to be updated

JemDay · 2019-07-15T16:01:18Z

@duglin - I found the sequence/sequence weird as well, we might want to consider having guidance of extension writers to use more terse naming (much like JWT's).

duglin · 2019-07-15T16:11:26Z

@JemDay I agree, but I wasn't suggesting that it should be that way. I was just showing what it would look like if you blindly squashed things. In a real-world situation, I wouldn't name things such that I ended up with sequencesequence - I would be a better smarter about it :-)

JemDay · 2019-07-18T15:44:12Z

Another attempt to clarify my concern with the proposed changes - how do we move between structured mode, binary mode, and back without loss?

(1) Start with a structured event

Content-Type : application/cloudevent+json
Content-Length : nnnn

{
    "specversion" : "0.5",
    "type" : "org.jem.example",
    "time" : "2019-07-18T16:26:00Z",
    "id" : "aaaa-bbbb-cccc",
    "sequence" : {
        "sequence" : "99",
        "sequencetype" : "Integer"
    },
    "bbs" : {
        "ctx" : "ABCD",
        "correlation" : "111-222-333"
    },
    partionkey : "P1",
    "data" : {
         "message" : "The quick brown fox jumped over the lazy dog"
    }
}

(2) Now, re-encode it into Binary

Content-Type : application/json
Content-Length : nnnn

ce-specversio" : 0.5
ce-type : org.jem.example
ce-time : 2019-07-18T16:26:00Z
ce-id : aaaa-bbbb-cccc
   
---- Fill in the blanks using your favorite scheme
---- then proceed to (3)

{
    "message" : "The quick brown fox jumped over the lazy dog"
}

(3) Proof

So, only with the information above , how do you transform the binary representation into the structured one we started with using the various binding sprecifications.

If you can show a translation from (2) -> (1) with no prior knowledge of (1) then i'm happy.

I believe my proposal (further up the PR) 'restricting a extension to be a bag-of-strings (or primitives)', eg using an ce-bbs-ctx scheme allows for this to occur.

evankanderson · 2019-07-18T16:43:26Z

@evankanderson I think this line: https://github.com/cloudevents/spec/pull/467/files#diff-958e7270f96f5407d7d980f500805b1bR422 might need to be updated

This specification places no restriction on the type or semantics of the
extension attributes.

We should probably fix that sentence anyway; we don't support sequences (arrays) or many other types (including boolean).

evankanderson · 2019-07-18T17:14:39Z

Summary of pros and cons. Note that the "Cons" are motivations to accept this proposal, and the "Pros" are motivations to ignore this proposal.

Cons of having Maps as context attributes

Adds an extra (fairly complex) concept from the type system
Without custom mapping (like HTTP), it is hard to filter on Map-valued attributes
Unknown extensions in the SDK currently are of type Or<String, Map>, which is awkward
- And might not work (i.e. returned type might be String) for some transports like AMQP
Map does not match the underlying header semantics on 6 surveyed transports
Minor cons
- HTTP has only a single non-alnum character for header key separation; by using this for Map, we have no separators in context attribute names
- Maps are recursive, it's not clear that HTTP handles the recursive case

Pros of having Maps as context attributes

Allows nesting of objects for association
Allows using a Map as a namespace for extension
Maps naturally in some languages

evankanderson · 2019-07-18T17:46:40Z

With respect to Jem's example, I would recommend the following instead:

(1) Start with a structured event

Content-Type : application/cloudevent+json
Content-Length : nnnn

{
    "specversion" : "0.5",
    "type" : "org.jem.example",
    "time" : "2019-07-18T16:26:00Z",
    "id" : "aaaa-bbbb-cccc",
    "datacontentype": "application/json",
    "sequence" : "99",
    "sequence_type" : "Integer",
    "bbs_ctx" : "ABCD",
    "bbs_correlation" : "111-222-333"
    "partion_key : "P1",
    "data" : {
         "message" : "The quick brown fox jumped over the lazy dog"
    }
}

(2) Now, re-encode it into Binary

POST /... HTTP/1.1
Content-Type: application/json
Content-Length: nnnn
CE-Specversion: 0.5
CE-Type: org.jem.example
CE-Time: 2019-07-18T16:26:00Z
CE-Id : aaaa-bbbb-cccc
CE-Sequence: 99
CE-Sequence-Type: Integer
CE-Bbs-Ctx: ABCD
CE-Bbs-Correlation: 111-222-333
CE-Partition-Key: P1

{
    "message" : "The quick brown fox jumped over the lazy dog"
}

In addition to this PR, this assumes a second PR which would add "" to the allowed set of interior characters in context attributes (i.e. not "foo" or "foo"). "" would be a language- and content-encoding specific delimiter character; in HTTP, it would be mapped to "-" (and the character after a "-" would be capitalized in this implementation, though HTTP headers are case-insensitive). "_" is chosen over "-" or other characters as it is a valid separator character in most programming languages, even though it is uncommon in HTTP header names.

cneijenhuis · 2019-07-19T07:04:40Z

this assumes a second PR which would add _ to the allowed set of interior characters in context attributes

As I said on the call, this was already discussed in the working group. I personally did not agree to do away with any kind of separation between words, but the working group had a vote and accepted the proposal by Clemens. See #321 , in particular

To make up for the loss of the word separation by case, it would be great to have some kind of word separator available in addition to lower-case letters and digits, but dots and dashes and underscores clash with identifier rules in various languages/protocols. I don't think the result is all that terrible and the wire doesn't care about aesthetics.

While I personally don't like the tradeoff made in #321 (and have voted against it), I'd prefer if we can just keep it as-is and move on. Re-discussing all tradeoff decision every couple of months is not a good way to make progress towards a 1.0 😉

duglin · 2019-07-23T03:09:47Z

Focusing just on this one:

Unknown extensions in the SDK currently are of type Or<String, Map>, which is awkward

I'm curious to know how people expect SDKs/code to deal with this.

When the extension is in a format like JSON then I suspect the answer is the same as how you'd deal with any unknown JSON property since that could be a singular value or an object/map.

When we're dealing with binary mode, e.g. http binary, and we allow any arbitrary depth of maps, then it's harder. However, if we limited maps to just one level and kept the binary serialization as ce-map-key=value then that should be easy to reconstruct as a map - which then puts us back to the previous state of how to return a map vs singular value back to the app.

I'd like to know what people think about the compromise position that @JemDay mentioned... keep maps but just limit them to one level.

duglin · 2019-07-26T13:48:10Z

At the end of this discussion on yesterday's call we briefly touched on whether maps could be added back in post v1.0. At the time I had my doubts, however I now wonder if we could add them by doing this:

add something to spec today that says something like: as a consumer if you get an attribute that starts with "ce-" but then contains characters that are not allowed to be there, then you MUST generate an error and not process the message beyond the logging or error reporting aspect of it. Meaning, no business processing at all.
if in v1.1 we add maps back in, then the - char will suddenly be a valid character. Which means an existing v1.0 consumer will still continue to error on it, but a v1.1 consumer will work just fine. So, while we can't force a v1.0 consumer to understand a v1.1 message, we can guarantee that it won't let it thru and there's a way for the sender to detect that it wasn't just ignored (assuming it can check the logs).

Thoughts?

evankanderson · 2019-07-31T07:09:56Z

Assuming that we want to remove Map from context attributes (but retain it as a possible expansion of Any in the data payload), I think this is ready to vote/merge.

I may be out on Thursday; I'll see whether I can make the call, but I have a meeting conflict at that time.

Secondary question -- would you prefer that I squash the commits before this is merged?

duglin · 2019-08-02T14:05:27Z

Given the magnitude of this change, we decided to start an async vote that ends at the start of next week's call. The following have voting rights:

Adobe, ControlBEAM, Google, IBM, NATS/Synadia, PayPal, Red Hat, RX-M, SAP, VMWare, Vlad Ionescu, Erik Erikson

You can either vote via comment in this PR or at the start of the call next week - but a vote via comment (with reasons why) would be great for those who are unsure and would like to understand your reasoning.

rperelma · 2019-08-08T03:58:05Z

I vote in favor of this proposal, i.e. removing Map from the set of supported attribute types, and the reason is because it adds complexity to the spec, as has been discussed extensively in this PR.

deissnerk · 2019-08-08T13:36:43Z

SAP votes for approving this PR.

Vlaaaaaaad · 2019-08-08T15:16:11Z

I'm in favor of this PR.

We'll make a decision now, release 1.0-rc1 and as per Doug's comment we'll see what the real world feedback is.

markpeek · 2019-08-08T15:18:25Z

VMware votes for approving this PR. Agreed with simplicity for 1.0.

ColinSullivan1 · 2019-08-08T15:58:03Z

Synadia votes to approve. Keep things simple. Maps can be added in the future if deemed necessary through a use case.

…review. Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>

evankanderson added 5 commits June 24, 2019 08:58

Remove Map from allowed Context Attribute types

38b7a35

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>

Merge remote-tracking branch 'upstream/master' into where-were-going-…

f547f7c

…we-dont-need-maps

Add Any-context type.

e53d0eb

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>

Make formatting of Any-context explicit in transports/formats.

0fd273f

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>

Fix capitalization of MAY NOT/SHOULD

9997916

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>

This was referenced Jun 24, 2019

Revise Map encoding for attributes in AMQP #460

Closed

Adding a transformer to support PubSub Push format conversion. google/knative-gcp#46

Merged

duglin added the v1.0 label Jun 24, 2019

duglin reviewed Jun 25, 2019

View reviewed changes

n3wscott mentioned this pull request Jun 26, 2019

Revisit CloudEvents attributes google/knative-gcp#58

Closed

duglin reviewed Jun 27, 2019

View reviewed changes

clemensv reviewed Jul 1, 2019

View reviewed changes

evankanderson commented Jul 2, 2019

View reviewed changes

Update with suggestions from PR=

88ebfd7

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>

evankanderson mentioned this pull request Jul 2, 2019

Define several tricky cases for encoding based on spec. #456

Closed

Merge changes to spec.md

770b8de

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>

duglin reviewed Jul 3, 2019

View reviewed changes

Change wording to make it clear that Any which doesn't result in `M…

008fa09

…ap` is allowed. Signed-off-by: Evan Anderson <argent@google.com>

duglin merged commit 37bc677 into cloudevents:master Aug 8, 2019

evankanderson added a commit to evankanderson/spec that referenced this pull request Aug 13, 2019

Remove map after cloudevents#467. Clean up JSON a little per @duglin …

ef0712a

…review. Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>

n3wscott mentioned this pull request Sep 20, 2019

Remove support for maps in attributes. cloudevents/sdk-go#196

Closed

Remove Map from allowed Context Attribute types #467

Remove Map from allowed Context Attribute types #467

Conversation

evankanderson commented Jun 24, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jroper commented Jun 25, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

duglin commented Jun 27, 2019

clemensv left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

evankanderson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JemDay commented Jul 10, 2019 • edited Loading

duglin commented Jul 10, 2019

evankanderson commented Jul 11, 2019 • edited Loading

JemDay commented Jul 12, 2019 • edited Loading

HTTP, Structured, JSON "data"

HTTP, Binary, JSON data

duglin commented Jul 12, 2019

JemDay commented Jul 12, 2019

duglin commented Jul 12, 2019

duglin commented Jul 12, 2019

duglin commented Jul 15, 2019

JemDay commented Jul 15, 2019

duglin commented Jul 15, 2019

JemDay commented Jul 18, 2019 • edited Loading

(1) Start with a structured event

(2) Now, re-encode it into Binary

(3) Proof

evankanderson commented Jul 18, 2019

evankanderson commented Jul 18, 2019 • edited Loading

evankanderson commented Jul 18, 2019

cneijenhuis commented Jul 19, 2019

duglin commented Jul 23, 2019

duglin commented Jul 26, 2019

evankanderson commented Jul 31, 2019

duglin commented Aug 2, 2019

rperelma commented Aug 8, 2019

deissnerk commented Aug 8, 2019

Vlaaaaaaad commented Aug 8, 2019

markpeek commented Aug 8, 2019

ColinSullivan1 commented Aug 8, 2019

JemDay commented Jul 10, 2019 •

edited

Loading

evankanderson commented Jul 11, 2019 •

edited

Loading

JemDay commented Jul 12, 2019 •

edited

Loading

JemDay commented Jul 18, 2019 •

edited

Loading

evankanderson commented Jul 18, 2019 •

edited

Loading