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

I'm going to weigh in on the side of well-known strings. The idea is that you would only have a very limited number of them for the most widely recognized payment methods. I wouldn't underestimate the effect that elegance has on the adoption of a standard. It makes a difference when developers look at our code examples and go: "This looks really clean."

Also I dislike the idea of tying widely supported standards to domain names. Whoever owns the domain for a widely supported standardized payment method today, I don't know whether that'll still be the case ten years from now and what that URI will dereference to, so for payments methods that are actual published specs/recommendations from a major standards body, it seems safer to have a well-known string. For that (limited) case, the ability to dereference actually **introduces** issues of ensuring continuity in the ownership and operation of that domain etc. that can be avoided by using a neutral string.

Lastly if I think of other standards, this pattern seems to have worked well in the past. I'm happy that I can write `<link rel="stylesheet" .../>` instead of `<link rel="http://www.w3.org/2010/rels/stylesheet" .../>` or some such. Yes, I realize the latter may be the The Right Thing To Do, but for well-known values that are perhaps even part of the original standard it makes way more sense to use well-known strings.

Standards should be designed for humans (developers) not for machines. Humans will say "stylesheet" and (correctly and quite reasonably) expect you to know what they mean. That was the problem with the whole XML debacle in that it was very rigorous and well intentioned, but ultimately not designed for humans.

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