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

@msporny,

Regarding the two proposals, yes, that would be my preference but I believe the group likely needs more information on the cost of supporting both short strings and URLs.

Regarding your list of six points:

* Versioning. This sounds useful, but I'd like to hear from people with more API design experience (and on how it is done).
* Machine readability. I can see a case for having a machine-readable expression of short strings (e.g., validity checking of some sort). We could discuss various ways to publish the data (in the spec, with the spec).
* Nature of registry. As I wrote, I have a mild preference for having the spec (including any machine readable info) be the registry while we have an institutional commitment through the WG. But I understand the case for making it easier to update the registry through some process.
* Regarding "The behavior of unknown payment message data is undefined." I would phrase it this way:
If we support short strings, then if implementations of the API encounter undefined short names, we should be sure to address error handling in the API specs.
* Regarding "There is a formal mechanism for expressing the payment method registry (like a JSON-LD context).": the specification would be the formal mechanism. So I think this bullet goes away in favor of the previous one on machine-readability.
* Regarding "Payment message data should be designed to have meaning outside of the context of an API call defined by the group.". I think that's close to the question, but perhaps the key point has to do with the data being self-defining (is that the phrase?) via URLs that enable discovery of the context where the data are defined?



---
Reply to this email directly or view it on GitHub:
https://github.com/WICG/paymentrequest/issues/35#issuecomment-169799228