Skip to content
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

Closed
tjanczuk opened this issue May 5, 2018 · 8 comments
Closed

JSON Event Format processing #185

tjanczuk opened this issue May 5, 2018 · 8 comments

Comments

@tjanczuk
Copy link

tjanczuk commented May 5, 2018

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?

@duglin
Copy link
Collaborator

duglin commented May 9, 2018

@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?

@duglin duglin added the v1.0 label May 10, 2018
@jroper
Copy link
Contributor

jroper commented Jul 2, 2018

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 text/, eg text/plain, then it should be treated as a String, otherwise, as binary.

@duglin
Copy link
Collaborator

duglin commented Oct 30, 2018

Seems related to #184

@duglin
Copy link
Collaborator

duglin commented Oct 30, 2018

@clemensv any comment on this one?

@duglin duglin added v0.2 and removed v1.0 labels Oct 31, 2018
@duglin
Copy link
Collaborator

duglin commented Nov 1, 2018

is "data" the only one with this problem? I'm wondering if we resolve #184 and #261, would this issue implicitly be solved too?

@clemensv
Copy link
Contributor

clemensv commented Nov 6, 2018

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.

@duglin
Copy link
Collaborator

duglin commented Nov 8, 2018

All - does #343 address your concerns?

@duglin
Copy link
Collaborator

duglin commented Nov 21, 2018

@tjanczuk @jroper ^^

@duglin duglin removed the v0.2 label Nov 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants