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

@ianbjacobs,

> The goal of "custom" was not to tell people how to write their extensions. Only to tell browsers: "I am explicitly asking you to leave this untouched."

It also says that an extender can't decorate the payment request as they see fit, essentially making "annotations"/adding properties along side various parts of the standard request. I consider having the freedom to do that to be a more powerful and developer-friendly/author-friendly extension approach.

> If you have processing rules that say "Leave everything you don't understand untouched" then I don't know how you detect error cases.

What errors are you worried about? Can you provide some use cases?

> For the time being, we have resolved to serialize the development of the APIs, so my expectation is to come to ground first on the browser API, then apply what we've learned to the HTTP API. That's not the only way imaginable, but that's what we've decided.

Yes. That doesn't meant that we shouldn't keep this stuff in mind as we go -- it just means that getting the alignment right may be more difficult and require more iterations. I got the impression that the parties that may benefit most from alignment (retail, merchants, banks, etc.) don't have adequate technical representation. Therefore, the decision seemed to be made more out of a desire to get along, keep momentum, and some indifference (for those parties only interested in the Browser API).

> I was thinking rather organizing the JSON-LD as a layer on top of the others, like this:
> 
>  - Here are the specs that define the Web Payments API. (However that's done with 1 to N specs).
>  - Here's a companion spec that says how you use the Web Payments API with JSON-LD.
>
> Thus, if we have JS and HTTP specs that require JSON, the companion spec could say
how to use both of those with JSON-LD.

I'm not convinced that's the best way to do it, but I do see it as a potential fallback option. I'd rather us just use a format that can be used as regular JSON but also has a well-defined extension mechanism that can be safely ignored (JSON-LD). That mechanism is recommended for extensions as it will achieve the best interoperability, but it is not required (you can do anything provided you don't mess with well-defined properties). I would think that could be just as acceptable to those that don't care about LD and don't want to deal with any LD processing, but would give clearer guidance on how to best write extensions.

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