Earlier quoted context omitted.
Keep on turning the crank ... What if you need something but don't know its name or URL? Etc.
My example definitely presumed things like service discovery which gets you to URLs. But I think I see the larger point you make about what if you don't even know what kind services are available (which my example assumes you already know) and once told of their existence how do you negotiate their capabilities and usage (my example, as I envisioned it, completely falls apart here without some major plumbing which mi…
One thing I've found about the web, as it exists, is that the people who set up a system for the outside world to use change it over time. The URLs change. The CGI their service will accept changes. As things exist now, a program must use "sticky" names, and if a name changes, all of a sudden the connection is broken, even though the exact same functionality still exists. It would be good if a program could find the functionality it needs based on a functional description of what it needs, rather than a name. That gets more to what's really important. I once complained to Alan that Smalltalk had the same problem. If I change the name of a class, all of a sudden all the code in the system that needs that class could no longer find it, even though I had changed none of its functional code. This seemed like an extremely brittle scheme for finding resources. The name is not the important thing about what a program needs. It's just a reference point that does nothing. Names are still good, because they allow us to quickly identify resources, but they should mainly be for us, not the program, because when you really think about it, a program doesn't care what something is called.