Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)


I recognize the value of grounding the meaning of the terms. However, the argument has
been made in other contexts that prefixing mechanisms that require developers to put context explicitly in code as a separate URI can make the code more brittle (e.g., in the face of cut and paste). 

Can we make the grounding implicit? The API overall would be grounded (either to a specific version of the API if that's what's needed, or a latest version potentially if the application prefers that approach) and that's where one would find the definitions of the short strings. We would avoid changing the meaning of a short string over time (at least in ways that would lead to incompatibilities in deployed software). Thus, we could use 'visa2' to signal a significant change from the meaning of 'visa'. This would simplify life for developers and avoid the confusion and cost of relying on dereferencing a URI to establish that identical strings in fact mean different things.

In exchange for this reduction in flexibility, I still favor the ability to use either a short string or a URL to identify a payment app. I recognize that this option increases the processing cost for implementers.


Reply to this email directly or view it on GitHub:

Received on Thursday, 7 January 2016 16:12:07 UTC