Hi,
(If you're in a hurry, you might want to skip to the end of the mail, since
the conclusion is partly unrelated to my in-depth analysis of the problem)
it seems PHD is completely innocent for this bug. Upgrading PHD didn't seem to
help (though I'm not 100% sure that the upgrading worked, I did throw out the
old version entirely). From configure.php, it seems that this error occurs
when asking the DOMDocument builtin PHP class to validate, even before PHD is
called at all.
Instead the manual.xml validation errors reported here seem to be caused by
recent changes in libxml2, as suggested in this post:
http://www.mail-archive.com/x...@gnome.org/msg07188.html
Apparently, there was recently a change in libxml to pass on the current
default namespace when expanding entity references. This was a change to fix
this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=502960
This problem seems to occur when the entity referenced actually contains
complete nodes, which don't have an xmlns= of themselves. The workaround
suggested in the first post above is to explicitly define a default namespace
inside the node(s) generated by the entity.
From (quickly) looking at the source, for when the Namespace default prefix
was not found error occurs, it seems that the following happens:
* A new node (presumably from an entity reference) is created, which gets the
current default namespace passed in (presumably from the node that
references the entity) (xmlSAX2StartElementNs() in SAX2.c)
* The new node checks his default namespace, using the xmlSearchNs function
from tree.c. Its documentation says: We don't allow to cross entities
boundaries. If you don't declare the namespace within those you will be in
troubles !!! A warning is generated to cover this case.
* The namespace could not be found, generating the Namespace default prefix
was not found error.
This seems related to this (old) bug, marked wontfix:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174793
This post, from 2002 suggests that the behaviour for xmlSearchNS above is
actually a libxml2 bug, but one whose workaround is good practice anyway:
http://mail.gnome.org/archives/xslt/2002-January/msg00022.html
This post concerns explicit namespace prefixes in entities, which are not
declared in the entity itself.
However, it is my suspicion that the recent change in libxml is now causing
the libxml bug from 2002 to appear for entities that don't declare a default
namespace either (previously, the node inside the entity just wouldn't have
any namespace associated with it, which was probably not correct either, but
did validate, since xmlSAX2StartElementNS() didn't try to check the namespace
at all).
So it seems the official workaround to this is declaring a default xml
namespace inside each entity declaration (I haven't tried this). I don't know
enough of the XML (NS) specification to know if this is a real solution or if
libxml2 should really be fixed instead...
However, it seems that this problem really isn't Debian specific, so upstream
should be seeing the same problems. Looking at the latest upstream version of
the documentation, it sems that upstream has already applied the workaround.
For example, the frontpage.authors entity at:
http://svn.php.net/repository/phpdoc/en/trunk/contributors.ent
Closer inspection shows that this is fixed in r290424 and r290427:
matth...@xanthe:$ svn log -c 290424 -c 290427
http://svn.php.net/repository/phpdoc/en/trunk
r290424 | bjori | 2009-11-09 16:58:06 +0100 (Mon, 09 Nov 2009) | 3 lines
Add namespace declaration to all free standing elements
# See https://bugzilla.gnome.org/show_bug.cgi?id=502960
r290427 | bjori | 2009-11-09 17:04:52 +0100 (Mon, 09 Nov 2009) | 3 lines
Adding namespace declaration to newly introduced entities
# See https://bugzilla.gnome.org/show_bug.cgi?id=502960
So, it turns out we can easily fix this problem by packaging the latest
version of the php documentation. Considering that we're currently shipping a
version from 2008, that seems like a good idea anyway.
It's not exactly obvious to me how the documentation stuff is organized and
how to get a orig tarball from upstream's svn (it seems that the Debian
package merges a few directories from SVN?), so I haven't tested this theory.
There's probably more things to fix when upgrading, though.
Lior, could you take care of this upgrade? If not, I can see if I can prepare
something, since I'd like to preserve php-doc (though I don't have too much
time, of course :-p).
Gr.
Matthijs
signature.asc
Description: Digital signature
