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

@dlongley,

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."

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

You asked: "Do you agree then that we should start from a point of convergence and then only diverge as needed? ". No, that's not how I would start. But I have not tried to do this so I don't know how my approach(es) would fare.

>  Perhaps our most recent approach in this discussion has been a bit backwards -- why not restart by assuming we can use the same messages and then only deviate from that if we really need to?

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.

> I'm ok with that, in fact, I think that spec should be the messaging spec. 

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.

Ian

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