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

More fully expanding on @annevk's and @msporny's comment:

URLs are a terrible anti-pattern for identifiers, as has been proven over and over and over again every single time someone tries to use them as such.  The canonical anti-example is XML namespaces, but every use suffers from the exact same problem, which is that identifiers want to be opaque strings, but URLs are *not* opaque strings to humans. URLs come with meaning, and with forgiveness in how precisely one can write it.  In particular, most humans would consider all of the following to be "the same URL":

* http://www.example.com
* https://www.example.com
* http://example.com
* http://www.example.com/
* http://www.example.com/#
* + combinations of the above variations, and more

Using URLs also encourages people to make those URLs resolvable. Most of the time the people suggesting this seem to think this is a *good* idea (as you seem to, with your comment that "the publishers may wish to use URL identifier that points to a resource like their homepage, the registration page for the app or a manifest for the app.").  Again, many experiences over the years shows that this is a very bad idea, for multiple reasons:

* Sometimes URLs become extremely popular, and tools end up effectively DDOSing the endpoint (the W3C has had to spend significant effort/expense making their servers capable of handling all the requests coming in for namespace URLs).
* Business URLs change.  They switch to https, or the company name changes and they change their domain to match, or the company dies and someone else uses the URL, but the service the previous business started is still used.  (There's been pushback from important/respected parts of the Semantic Web community against the "use HTTPS everywhere!" mandate, because it changes urls and the namespace & identifier URLs they were using in their ontologies are no longer "correct".)
* More specific urls (to particular endpoints within a server) change *commonly*, especially if they don't actually *do* anything but maybe serve some explanatory text.
* Even dedicated "live-forever namespace URLs" services die. There are a few that have stood up for years, but plenty of others that have died and been forgotten.

The only reason to use URLs is that it's a globally unique name registry that someone else is already spending the effort to maintain.  But that's seriously not a big deal; for all but the most prolific services, running a name registry is trivial and cheap.  You can get vastly better ergonomics just by doing it yourself (or having the W3C do it).

-- 
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-239520278