This was a frustrating issue I banged my head up against for a while, so I’m explaining it here in the hopes that it helps someone else. This isn’t actually specific to PhpDocumentor at all; that’s just where I saw it come up. Phpdoc was generating some intermediary files just fine but failing to generate its final HTML and it was spewing a bunch of messages that look like these:

PHP Warning: XSLTProcessor::importStylesheet(): error in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 62

PHP Warning: XSLTProcessor::importStylesheet(): Local file read for /usr/share/php/phpDocumentor/data/templates/responsive/layout.xsl refused in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 62

PHP Warning: XSLTProcessor::importStylesheet(): error in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 62

PHP Warning: XSLTProcessor::transformToUri(): No stylesheet associated to this object in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 138

A quick spin on Google helped me find other people with the same or similar problems but didn’t yield a solution. After too much time spent methodically backing out some recent changes on the system, I found that disabling PHP support for librdf (aka the Redland PHP interface) made the problem go away.

An example of where this corollary could be applied is in some browser developers’ handling of HTTP’s 301 Moved Permanently responses. According to RFC 2616, section 10.3.2 301 Moved Permanently:

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

That’s all well and good but permanence is an elusive thing on the web. Websites and applications tend to change quite a lot, especially during development. And when aren’t they under development? Even if mistakes were never made, the ownership of domains (and therefore URIs) is subject to change.

None of that would pose a problem in this instance if it weren’t for browser developers who cache 301 responses for a resource indefinitely and use one of the returned URIs for all future references to that resource.

But, but, but! . . . That’s what the RFC says they SHOULD do, right? And isn’t a good thing that they want to be called unconditionally compliant?

Yes. But that misses the point. The phrase any future references to this resource can be quite flexibly interpreted. Any future references handled by what exactly? Some browser developers have decided it should mean any future references handled by an installation of their browser. It would be a lot more reasonable, especially from the perspective of web developers, if the browser developers simply interpreted it to mean an instance instead, at least, in the absence of specific caching instructions.

Here is an awesome rant on the feeble vision some big players have for the future of interaction design.

The author, Bret Victor, a onetime human interface inventor at Apple, complains that the vision of the future where we are sliding around pictures behind glass isn’t really visionary but just a tiny step from where we are now.

I’m inclined to agree.

Moreover, I think this vision isn’t just limited; it’s limiting too. If we can’t conceive of richer ways to interact with our computers, we’ll be restricting our ability to see what problems we can solve with them.