Re: Cocoon config: chasing namespace URIs?

[Igor Naumov]

It might be possible  that your  application  is going to w3.org for some DTD (e.g. for XML/XHTML validation). However I am not sure how to prevent this (or even if it make sense to avoid retrieving a DTD). Igor Fred Vos wrote: Hello Steve, On Fri, Jun 16, 2006 at 08:38:31PM -0400, Steve Burling wrote: To make a long story short, the machine running the site has apparently lost the ability to contact www.w3.org. Of the half a dozen other machines on our network that I tested, all except the problem machine could contact www.w3.org, and aren't exhibiting any problems. The only references to that site that I've found are in namespace definitions like these: <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:c-insert="http://apache.org/cocoon/insert" xmlns:xhtml="http://www.w3.org/1999/xhtml"> I'm not an XML expert; I just run the sites for the folks who are, but my limited understanding of namespace definitions leads me to believe that it is the *value* of the attribute, not what it points to, that matters, and in fact <http://www.w3.org/1999/XSL/Transform> (for example) is just a simple web page that doesn't look like it'd be useful to an XSLT processor in any way. So, the question: *Is* Cocoon attempting to de-reference that URI? And if so, is there a knob somewhere I can turn to make it stop? No. Namespace URI's are just strings. They do not have to point to an existing host or document. In the case of an xsl stylesheet, they must only match the namespace URI's for prefixes in the document you are processing. Since these URI's are strings, these must match perfect. I've once spent hours and hours searching for the cause of a problem, where an extra slash in one of the namespace URI's, made the match of URI's fail. My guess is that you cannot reach w3c because of some network problem, but that this network problem is causing errors somewhere else. Fred