Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27)

@dlongley,

You wrote:

> I expect there to be more than one place where data can be extended. So we'd end up sprinkling "custom" bits just about everywhere. Either that, or people may end up having to duplicate bits of the payment message in the custom section, leading to bloat and potentially errors or confusion.

Maybe. And we should keep discussing the use cases. As I said I don't feel strongly about that particular approach; I just think it's worth considering explicitly the case of "leave untouched" versus errors/mistakes. Also, is there some reason why all the custom bits can't be put in one place? 

> A compromise might be to say -- if you're extending via JSON-LD, then a @context must be present, which is also a trigger that means you can then extend however you want (with the obvious caveat that you can't stomp on well-defined properties). If no @context is present, you can throw errors for unrecognized properties.

It seems to me that if @context is present, then any app that handles JSON-LD will know what to do. Therefore, if you are extending with JSON-LD, the Web API specification doesn't need to say anything because the conformance requirement is on the app, not the API implementation.

I don't know JSON-LD well enough. How does any processor know that the payload is JSON-LD? Does encountering @context suffice?






---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/27#issuecomment-178946073