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

@ianbjacobs,

> I believe we should not today tell people there is only one way to extend the data.

In my view, saying that all of the extensions go under a special "custom" property would do just that.

> We should take pains so that we don't prevent people from trying different approaches.

I agree, which is why I think the best approach is to simply define what is known and used by the API and leave the rest alone. We don't need to tell people that they have to put all of their extensions in a special spot -- as that creates limitations on a particular extension approach, namely the first suggested extension approach that is under consideration right here in this issue.

I expect people to want to be able to add their own properties to payment method information, to the top-level payment request, to ... whatever. Telling them that they can't decorate the payment request as they see fit and, instead, they must all use a special "custom" box is definitely limiting certain extension approaches.

> It seems to me that a Web API spec requiring conformance to JSON would do the right thing (provided the payment app knows how to handle the data you feed it). Am I mistaken?

This has to do with the next point...

> As I've mentioned elsewhere on threads, I share the goal of avoiding divergence between the JS and HTTP APIs. I do not consider it a requirement that the APIs use the same data (and there may be good reasons not to, such different security requirements in different ecosystems). But I agree it would be good to avoid unnecessary divergence.

Do you agree then that we should start from a point of convergence and then only diverge as needed? That is my view. The Web Payments CG spec also reflects this approach. 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?

> The WPWG publishes a companion spec that says "If you want to use JSON-LD, here's how you do it."

I'm ok with that, in fact, I think that spec should be the messaging spec. The Browser API spec can reference that spec (as can the HTTP API spec). That's the design we've gone with in the Web Payments CG specs. For example, the Browser API could have a small section that says that you can "transform" the messages used in the Browser API spec to match the Messaging spec by adding the default `@context`.

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