Re: [w3c/browser-payment-api] Define payment option filtering algorithm. (#420)

domenic commented on this pull request.

I'm rather confused, so I tried to ask clarifying questions...

> @@ -628,30 +628,21 @@
           <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>Consult the appropriate <a>payment apps</a> to see if they
-              support any of the <a>payment method identifiers</a> given by the
-              first element of the <var>paymentMethod</var> tuple, passing
-              along the data string given by the second element of the tuple in
-              order to help them determine their support.
-              </li>
-            </ol>
-          </li>
-          <li>If this consultation produced no supported method of paying, then
-          reject <var>acceptPromise</var> with a "<a>NotSupportedError</a>" <a>
-            DOMException</a>, and abort this algorithm.
+          <li>Let <var>matchingOptions</var> be the result of running the

It's a little unclear to me what the result of this algorithm is, i.e. what a "matching option" is. The algorithm steps seem to only add _option_ to the return value, and _option_ is a payment app. So is _matchingOptions_ a list of payment apps? But then the subsequent sentence

> show a user interface to allow the user to interact with the payment request process, using those payment apps, matchingOptions, and payment methods which the above step identified as feasible

is confusing, since the above step only identified payment apps = _matchingOptions_, whereas this seems to be saying that there are three different lists determined by the above step: the payment apps, _matchingOptions_, and payment methods.

> +          Filter payment options algorithm
+        </h2>
+        <p>
+          The <dfn data-lt="filter payment options">filter payment options
+          algorithm</dfn> runs when user agent presents the user with the
+          collection of payment options available for selection. It MUST run the
+          following steps:
+        </p>
+        <ol>
+          <li>Let <var>matchingOptions</var> be an empty list.</li>
+          <li>Let <var>request</var> be the <a>PaymentRequest</a> object that
+          the user is interacting with.
+          <li>For each <var>requestMethod</var> in
+            <var>request</var>.<a>[[\serializedMethodData]]</a>:
+            <ol type="I">
+              <li>Let <var>filters</var> be <var>requestMethod.data</var>

This step doesn't make sense to me. requestMethod is a tuple containing supportedMethods, a `sequence<DOMString>`, and `data`, a string of serialized JSON. So `requestMethod.data` does not have any members.

> +          <li>Let <var>matchingOptions</var> be an empty list.</li>
+          <li>Let <var>request</var> be the <a>PaymentRequest</a> object that
+          the user is interacting with.
+          <li>For each <var>requestMethod</var> in
+            <var>request</var>.<a>[[\serializedMethodData]]</a>:
+            <ol type="I">
+              <li>Let <var>filters</var> be <var>requestMethod.data</var>
+                members whose values are lists of strings.</li>
+              <li>For each <var>option</var> of the installed
+                <a>payment apps</a>:
+                <ol type="i">
+                  <li>Let <var>optionMatch</var> be true.</li>
+                  <li>For <var>filterName</var> in the keys of
+                    <var>requestMethod</var>:
+                    <ol type="a">
+                      <li>If <var>option.capabilities</var> does not have key

Where is option.capabilities defined? I thought a payment app was an abstract concept, not an object which had properties.

-- 
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/420#pullrequestreview-21884586

Received on Tuesday, 14 February 2017 22:52:01 UTC