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

Simplified the example above. 

Note that one then has the flexibility to mix-in and compose PMI versions or treat them independently. 

```JS
// Mixin by bitcoin by version
const v1 = {
  supportedMethods: ["bitcoin-v1"],
  data: {
    /*v1 member*/
  },
};
const v2 = {
  supportedMethods: ["bitcoin-v2"],
  data: Object.assing(
    {},
    v1.data,
    {
      /*v2 stuff, trashes v1 stuff where it needs to - because mistakes were made*/
    }
  ),
};
const v3 = {
  supportedMethods: ["bitcoin-v3"].concat(v1.methods),
  data: Object.assing(
    {},
    v1.data,
    {
      /*v3 stuff, which is backward compatible with v1*/
    }
  ),
};
// Because v3 and v1 are compatible, we only list it once. 
// For legacy systems/reasons, we include v2, but we can 
// always fall back to v1.
const paymentRequest = new PaymentRequest([v3, v2], details, options);

// Or, we can support stricter fallback (although order doesn't matter!):
v3.methods.pop(); // Remove v1. 
const paymentRequest = new PaymentRequest([v3, v2, v1], details, options);
```

Anyway, unless I'm missing something, the using the version in the PMI seems optimal to me: 

 *  it gives complete data-type assurances with graceful degradation,
 * provides extensibility at every level (even in versions, with the addition of optional types) by allowing reuse of IDL dictionaries. You can import v1 things into v2 and vN.
 * and reduces overall redundancy.

Enough said... 
 
![obama-mic-drop](https://cloud.githubusercontent.com/assets/870154/26534227/511042b0-4465-11e7-8112-272e3bf000c6.gif)



-- 
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-304556749