@halindrome, I think there is a universal expectation to use JSON for messages. There is not, however, consensus to use JSON-LD. To foster adoption, I prefer a path that imposes the fewest constraints on the ecosystem. Therefore, I think we should define conformance to JSON, and allow that JSON to be JSON-LD where parties want to exchange JSON-LD. The reason I mention an attribute like "custom" is to distinguish two cases: * Custom data that should be left alone in processing * Errors I do not feel strongly about this, but it seems to me safer to distinguish those two cases where we can. I would like to hear whether something like "custom" is a common pattern in API design. I skimmed the API cookbook [1] but didn't see it there. (I didn't read the document closely, so it might be in there somewhere.) You wrote: "Just be descriptive about the things we care about, and permit the rest. " I agree. But "custom" says "We care enough to tell processors to leave this data alone and not deal with it in some other way that might be processor-dependent." Ian [1] https://www.w3.org/TR/api-design/ --- Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments/issues/27#issuecomment-178897822Received on Wednesday, 3 February 2016 00:04:13 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:14 UTC