Re: [w3c/browser-payment-api] Add extension point (#492)

marcoscaceres requested changes on this pull request.



> @@ -617,6 +617,20 @@
           </p>
         </div>
         <p>
+          The following algorithm provides an <dfn>extension point</dfn>: other
+          specifications that define more specific algorithms for matching the available 
+          <a>payment apps</a> to the provided <a>payment methods</a> are encouraged to
+          hook themselves into this specification at this point in the
+          algorithm.
+        </p>
+        <div class="note">

I suggest we remove this. I know I have it in the manifest spec, but I added this there originally because we were trying to understand the implications and process of monkey patching things back in 2014 - specially across disparate specs and standards orgs. Anne's post was certainly helpful in providing guidance. 

In our case, we are basically adding an extension point for specs that we will work on just within this working group. 

> +          <li><p><a>Extension point</a>: process any proprietary and/or other
+            supported algorithms, for determining the available methods of paying,
+            at this point in the algorithm.</p>
+            <p>Alternatively, the following generic algorithm may be applied:</p>
+            <p>For each <var>paymentMethod</var> in <var>request</var>.
+            <a>[[\serializedMethodData]]</a>:
+              <ol>
+                <li>Determine which <a>payment apps</a> support any of the
+                <a>payment method identifiers</a> given by the first element of
+                the <var>paymentMethod</var> tuple. For each resulting payment
+                app, if payment method specific capabilities supplied by the
+                payment app match those provided by the second element of the
+                tuple, the payment app matches.
+                </li>
+              </ol>
+            </p>

This markup is invalid. You can't have a `ol` inside a `p`. 

> @@ -665,17 +679,22 @@
           <li>Return <var>acceptPromise</var> and perform the remaining steps
           <a>in parallel</a>.
           </li>
-          <li>For each <var>paymentMethod</var> in
-          <var>request</var>.<a>[[\serializedMethodData]]</a>:
-            <ol>
-              <li>Determine which <a>payment apps</a> support any of the
-              <a>payment method identifiers</a> given by the first element of
-              the <var>paymentMethod</var> tuple. For each resulting payment
-              app, if payment method specific capabilities supplied by the
-              payment app match those provided by the second element of the
-              tuple, the payment app matches.
-              </li>
-            </ol>
+          <li><p><a>Extension point</a>: process any proprietary and/or other
+            supported algorithms, for determining the available methods of paying,
+            at this point in the algorithm.</p>
+            <p>Alternatively, the following generic algorithm may be applied:</p>

There can't be an "alternatively". Otherwise it reads as:
```
if (extension point) {
  // 
} else{
  // alternatively
}
```

What we want is:

```
try {
  async for (const extension  of extensions) {
    await extension.doYourThing();
  }  
} catch(err){
   return reject(err);
}
// do stuff that is already in the spec
// this spec always wins, because extensions points must not override default behavior 
```

-- 
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/492#pullrequestreview-30422981