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

@adrianhopebailie @ianbjacobs @shepazu, 

@dlongley and I have tried to formulate all of the discussion in this thread into a set of edits on the Web Payments CG Browser API. We just published a new version of the Web Payments CG Browser API with the following changes:

* JSON-LD isn't a conformance requirement for the Browser API (it was never intended to be, but the spec was mis-represented to the W3C team reviewers so here we are, and hopefully that point is more clear now). These changes are meant to address @ianbjacobs, @adrianhopebailie, and @shepazu's concerns. The API should also now look less scary to browser implementers and folks used to traditional W3C API specifications.
* There is now WebIDL for the bits that @adrianhopebailie wanted - PaymentApplication, PaymentRequest, and PaymentAcknowledgement are now fully specified in WebIDL. These sections can be found here:
* All of the JSON-LD guidance has been moved to a section titled "Extensibility". There is not /one/ way to do extensibility, but if you're going to do JSON-LD, there is guidance. This is an attempt at a compromise between @ianbjacobs, @rsolomakhin, @zkoch, and my position on the matter.
* The spec is now a low-level API and is designed to be paired with a higher-level API like the PaymentRequest API proposed by @zkoch and @adrianba or the Checkout API proposed by @dlongley here

Hopefully, this demonstrates that:

* @dlongley and I are monitoring the discussion and are responsive to changing the Web Payments CG specs based on the Web Payments WG discussion (even if we disagree with the direction).
* The Web Payments WG actually does have editors that will make a best effort at making spec edits if we have consensus from the group. I believe @zkoch and @adrianba are trying their best as well, it's just that the group hasn't made many decisions yet, so the editor's and implementers are left to sort of stab in the dark based on input from a minority of group members and see what happens.

The latest spec can be found here (if you see 9 ReSpec errors in red at the top, reload - one of the Javascript libraries we pull in is loading from a site that's experiencing some issues right now):

Are these changes enough to resolve this issue? If not, what further changes are required?

Reply to this email directly or view it on GitHub:

Received on Sunday, 7 February 2016 05:01:15 UTC