Re: [w3c/browser-payment-api] editorial: clarify that payment handler data is converted (#536)

@adrianhopebailie said:

> I think we should stop using WebIDL, I'm yet to hear a good argument why we are besides that it's easy to write specs with in ReSpec. As I suggested in that issue I think we should follow the data modeling language used for web app manifest.

> So are you suggesting that browsers will not accept any new payment methods in the ecosystem for which they haven't shipped built-in data validation?

> That's the opposite of the goal of this system.

> That simply won't work. The whole point of .data is that anyone can invent a new payment method with whatever data model they want in there. If they need browsers to ship new data validation for it then the whole design is broken.

I agree with @adrianhopebailie here as I did a long while back when this first came up in the WG. This is an important point -- and I believe Web IDL only leaked in here because the browsers were special casing basic-card because they were implementing it directly. This was an issue long ago in the WG where, as I recall, @adrianhopebailie, myself, and a few others were on the losing side of the argument but we foresaw saw this and other extensibility concerns (as mentioned briefly by @adrianhopebailie above).

I don't know what this means moving forward for telling browsers what to do here at this point, but I would very much like to see this information left as opaque as possible with respect to the browser implementation. Whatever we do, the key point is this: we do not want to create an environment where browsers must be upgraded in order to support new payment methods.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/536#issuecomment-304304708

Received on Friday, 26 May 2017 14:57:10 UTC