s/contenttype/datacontenttype/g#363
Conversation
|
I believe this makes sense ... we may need a communication strategy to address the fact that this is another breaking change which has potential to impact early adopters. Granted we're still in a sub 1.0 state but we might want to warn people off 0.2 if 0.3 (or 1.0) is considered close. |
|
Note: this will be discussed (and possibly resolved) on today's call and since this is a breaking change please speak up if you have any concerns. |
Closes cloudevents#354 2 reasons for this change: 1 - it just makes sense to me that if you have a `foo` property, then the property the describes its type is called `footype`, not `bartype`. 2 - when a transport, like http, already has a `contenttype` property, there could be unnecessary confusion when the CloudEvents property is serialized along side the transport one. Meaning, people might use the wrong one since their names are almost the same. Signed-off-by: Doug Davis <dug@us.ibm.com>
| 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 the `data` attribute of the envelope |
There was a problem hiding this comment.
Just the name change here... but things go pushed past 80 columns so I had to wrap stuff earlier.
|
Per the call yesterday I've changed the name to |
|
Just a poke to remind people to review this one as it's an attribute name change - this will come up today's call. |
2 participants
Closes #354
2 reasons for this change:
1 - it just makes sense to me that if you have a
fooproperty, thenthe property the describes its type is called
footype, notbartype.2 - when a transport, like http, already has a
contenttypeproperty, therecould be unnecessary confusion when the CloudEvents property is serialized
along side the transport one. Meaning, people might use the wrong one
since their names are almost the same.
Signed-off-by: Doug Davis dug@us.ibm.com