Skip to content →

Strange PhpDocumentor Issue

Published July 25, 2012 by jeremy

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::importStylesheet(): xsltLoadStyleDocument: read rights for /usr/share/php/phpDocumentor/data/templates/responsive/layout.xsl denied in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 62

PHP Warning: XSLTProcessor::importStylesheet(): compilation error: file /usr/share/php/phpDocumentor/data/templates/responsive/index.xsl line 3 element include in /usr/share/php/phpDocumentor/src/phpDocumentor/Plugin/Core/Transformer/Writer/Xsl.php on line 62

PHP Warning: XSLTProcessor::importStylesheet(): xsl:include : unable to load /usr/share/php/phpDocumentor/data/templates/responsive/layout.xsl 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.

With that knowledge, a new Google search turned this up this bug report.

For now, my workaround has been to avoid using Redland PHP together with libxslt but some additional digging suggests that this problem may be resolved by using a libraptor >= version 1.9.

 

Leave a Comment

A Robustness Corollary

Published January 31, 2012 by jeremy

You’re probably familiar with the robustness principle which is usually stated as:

Be liberal in what you accept, and conservative in what you send.

When it comes to standards, I’d like to offer a corollary:

Be precise in your description and flexible in your interpretation.

 

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.

 

Leave a Comment

Feeble Visions

Published January 18, 2012 by jeremy

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.

Leave a Comment