Re: [w3c/webpayments-method-identifiers] Why URLs? (#9)

> This is a fair point. We settled on URNs so we could make the statement that all payment method identifiers are URIs. The extra boilerplate seems minimal and low cost to me, but curious what others think. I could be persuaded to go with a simple string.

This is an argument based on spec simplicity, which is very wrong. Per the Priority of Constituencies (user > author > implementor > spec), spec simplicity is one of the lowest things to value.  You should be optimizing for author usability here.

> Yes, agreed on origin. There are a few additional values to using URLs over origins:

None of these reasons seem to be compatible with communicating with apps, which have an associated origin.  Multiple payment methods should indeed be suborigins (a trivial cost compared to actually running a second payment method server), and versioning can either be suborigins or communicated in the PaymentMethodData.

> No, there's a relationship. If we're going to show it, we have to be able to support it.

Right, but whether or not it's a URL has nothing to do with that.  There are many ways to potentially support open-ended payment methods.  In particular, it looks like y'all are supporting them via apps, which can be identified by an associated origin, rather than a full URL.  That's what I'm trying to say.

-- 
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/webpayments-method-identifiers/issues/9#issuecomment-239974977