I'm adding this fast, despite the fact that I think we're done talking about it for now. I figured history/meaning on classpath is important upfront. We don't have to discuss it more yet, but it will be a good way to show a) where it comes from b) how it is intended to work and c) why we should pass in the actual full name of the resource you are asking for (like including .php, .png, .twig, whatever).

In any event, the whole talk about classpath and what it means is another reason why I think talking about PSR-R later might be useful. :) It has no major impact on the question of what to do with PSR-X or even PSR Path Mapping. SUPER happy to talk about it later, but right now, I don't want to spend a whole lot more time on it.

> I removed the .php from the namespace. When a match is returned, it WILL have an extension.
>
> Namespaces do not have file extensions.

Yes, this is definitely a disconnect. :)

    $locator->findResource('classpath:///Acme/Demo/Parser.php');

What this does is say, "Find the physical path for the resource /Acme/Demo/Parser.php on the classpath." Classpath is a term I've seen used by Spring and it was a big influencer over PSR-0 Resource Locator and this whole concept of being able to locate files in a package based on a logical (call it a namespaced if you will) name.

I called them "namespacish" for PSR-0 RL but didn't really like it. Bernhard talked about "ns:" and "namespace:" prefixes. Ultimately it looks like we both liked "classpath" better. I'm happy with it, and I think it will clear up some ambiguities ("but they aren't namespaces!!!!" people would say; you and I can of course disagree with them, but I've made my peace by accepting that and trying to move forward with the whole logical mapping approach and ignore the question of "can we bring namespaces out to something more than just files?" by completely using a different approach and treat PHP namespaces as a specialization on the rule instead of trying to force people to look at it another way) by introducing a different word that does a pretty OK job of describing the same concept that namespaces do. Also, there is a precedent for something like this in the world of Spring. I think it would be a good idea following there.

So what classpath means, from my understanding, as it relates to PSR-R, "look for this resource (regular file or directory) amongst all of the registered namespace mappings (the classpath) to find a match."

This is more or less what Spring is doing in Java. You add paths and jars to the classpath, and then with Spring you can find any specific resource by asking for its path relative to the classpath root by saying "classpath:/WEB-INF/whatever/settings.xml". If the classpath is "/path/to/classes:whatever.jar:spring.jar:foo.jar", then it will look for the file at:

 * /path/to/classes/WEB-INF/whatever/settings.xml
 * (extract whatever.jar)/WEB-INF/whatever/settings.xml
 * (extract spring.jar)/WEB-INF/whatever/settings.xml
 * (extract foo.jar)/WEB-INF/whatever/settings.xml

... first one wins. Which is more or less what we are doing... if you consider the classpath to be a list of namespace mappings. :)

So we ask for specific file resources here, we don't ask for something like "Foo\Bar\Baz" and let the resource locator look for "Foo\Bar\Baz.php" or "Foo\Bar\Baz.json" or "Foo\Bar\Baz.png"... we ask specifically for what we want. The actual resource, as specified (including the extension!) must be there in order to be considered a match.

Stepping back now to PSR Path Mapping and PSR-X....

A PSR-X autoloader WILL be responsible for adding `.php` extension prior to asking the map for a match. That is not the responsibility of either the classpath handling in PSR-R or even in PSR Path Mapping.

To see an example of this, you can look here: https://github.com/simensen/psr-match/blob/master/example.php#L124-L132

```php
<?php

public function loadClass($class)
{
    // remove any leading backslash
    $class = ltrim($class, '\\');

    if ($match = match_path($class.'.php', $this->prefixes, '\\')) {
        include $match;
    }
}
```

All that PSR-X is, at this point, is taking the class name *as it is given to the callback directly*, and adding '.php' and passing it to PSR Path Mapping algorithm. So, when you ask for 'Foo\Bar\Baz', you actually end up passing it to the matching algorithm as `Foo\Bar\Baz.php`.

The same thing if you wanted to base a PSR-X autoloader off of PSR-R:

```php
<?php

public function loadClass($class)
{
    // remove any leading backslash
    $class = ltrim($class, '\\');

    // build a classpath resource URI string based on the classname
    $resourceName = 'classpath:///'.strtr($class, '\\', '/').'.php';

    // so: Foo\Bar\Baz => classpath:///Foo/Bar/Baz.php

    if ($match = $this-resourceLocator->findResource($resourceName)) {
        include $match;
    }
}
```

There is nothing in PSR-R or PSR Path Mapping that has anything to do with guessing extensions or anything. Those are both very specific. You get back what you ask for, verbatim, unless it flat out doesn't exist.

PSR-R does afford some additional mapping logic besides simply looking at a 1:1 map between a given path and the actual file on disk. That is where fun things like new schemes or tagging can come into play.

I think maybe you fancy the idea of having the ability to add "smart schemes" by which you can maybe do things differently like image:///foo/bar/thing ( => vendor/foo/bar/images/thing.png, vendor/foo/bar/images/thing.jpg)? This is of course something that we can look at supporting by way of specialized schemes (register a scheme, do cool stuff, implement an interface, whatever) but the classpath scheme is currently hardcoded to do a simple match against the registered PSR Path Mapping mappings and that is it. You ask for what you want, exactly, and you get it back if it is there. End of story.

Hope that helps explain classpath, at least in its current implementation, better. :)