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

> Yes, there should be a base request and response format for the Payment API.

There has been no opposition to this assertion, however there does not appear to be consensus on how this message schema should be defined. I have updated the title of the issue to focus on this question as it appears to be a fundamental difference between the two browser API proposals.

 * The [Web Payments CG](http://wicg.github.io/web-payments-browser-api/) proposal defines the messages as un-typed objects and asserts that JSON-LD would be used to define the format of these messages.
 * The [paymentRequest](http://wicg.github.io/paymentrequest/specs/paymentrequest.html) proposal defines the messages using WebIDL in the spec

There appears to be no precedent for a browser API to define un-typed parameters and I am not certain that the purported benefit of using JSON-LD, distributed extensibility, will be realized. (Browsers that implement the payments API will need to interpret the payment request object and will hard-code the expected message schema in their processing logic)

My suggestion would be for the payment request and response to be well-defined using WebIDL in either the browser API specification or a stand-alone message specification and for that schema to define extension points where custom payment method specific data is expected to be added.

The group may then decide to define a JSON-LD context or JSON Schema that aligns with the WebIDL message definition (alternative schema definitions for the same logical message object) which can be used for non-browser APIs or use cases (such as the HTTP API).

i.e. Define the payment request and response messages in WebIDL as the primary reference and then in other schema languages rooted in the WebIDL definition.

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

Received on Tuesday, 2 February 2016 12:51:29 UTC