-
Notifications
You must be signed in to change notification settings - Fork 584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JSON Event Format processing #185
Comments
@tjanczuk do you think this issue applies to all String attributes or just certain ones? I'm assuming the ones that use more specific types (like Timestamp) or say how the String must adhere to a certain spec are not of concern to you, correct? |
This definitely applies to the data attribute. A binary data attribute will be encoded as a JSON string, with the binary data base64 encoded. When it gets decoded, it will be decoded as a string. Now, the consumer could apply a heuristic, and say "this looks like a base64 encoded string" and so decide to decode as binary, but then what if the producer actually did want to produce a String that contains a base64 encoded value? For example, what if it's just emitting ids, and some of these ids happen to be bas64 encoded md5 hashes of file contents used to uniquely identify the file, and they want the consume to treat these as opaque strings? I think encoding to binary must be supplemented with additional information to indicate that it is binary, for example, we're already using the content type to determine whether the content should be treated as JSON, perhaps if it's not treated as JSON, and the content type starts with |
Seems related to #184 |
@clemensv any comment on this one? |
While I don't think there's a true conflict, I agree that some clarifications will be helpful in the spec. @tjanczuk The attributes are all typed, so there's no need for inference. However, there are a couple of bugs in that URI and Timestamp are missing constraints referencing RFC3986 and ISO8601. I'll address those. @jroper We have rules for how data and contenttype relate and they should not leave room for guessing. A base64-encoded hash is, absent a dedicated media-type, just another "text/plain" string. A protobuf payload would be a base64-encoded blob with an "application/protobuf" contenttype. Let me try to clarify these. |
All - does #343 address your concerns? |
JSON Event Format encodes several types of the Cloud Events type system into a JSON string. How is a consumer of a JSON encoded event expected to determine the intended type of a specific field of a Map? For example, how does the consumer determine if a string is a Timestamp, a base 64 encoded Binary, or just a String?
Is the consumer expected to be equipped with out of band knowledge to make this determination, or is the type of data expected to be described by a document pointed to by schemaUrl? If the latter, is there any prescription around what the schema of the schemaUrl document is?
The text was updated successfully, but these errors were encountered: