If there is a bug here then it is not with PHP. It is with libxml. You'd have to report the problem there.

But I don't see the problem. As you quoted, the processor may recover by reporting the erroneous value to the application - which is exactly what happened. Here's some formatting:

"the XML processor
- may report the error or
- may recover by
  * ignoring the attribute specification or by
  * reporting the (erroneous) value to the application"

Seems like you're interpreting it as "the XML processor may report the error or... by reporting the (erroneous) value to the application" but that doesn't make sense.


> and libxml_clear_errors() should be called internally before DOMDocument::load() returns
That would discard *all* errors during loading. A very bad idea.

requinix@php.net:

I've looked into this a little more and realized that LibXMLError has a $level property and that only when $level === LIBXML_ERR_FATAL does libxml consider the error to be a well-formedness error.  In the case of @xml:space it only considers it a LIBXML_ERR_WARNING.  Until now, I thought if libxml_get_errors() returned a non-empty array that it meant that libxml consider something to be well-formed error (my bad).

So, can you confirm for me that if DOMDocument::load() and DOMDocument::loadXML() return true that libxml_get_errors() is guaranteed to not contain any errors with $level === LIBXML_ERR_FATAL?

If so, then you can close this as "not a bug".

I can confirm [1] that if libxml says !xmlParserCtxt.wellFormed [2] and DOMDocument::$recover=false (the default) then PHP will return false.

I cannot confirm whether all LIBXML_ERR_FATAL are considered well-formed-ness errors, or the exact conditions for when wellFormed=0, but I think the answer to your question is basically still "yes".

[1] https://github.com/php/php-src/blob/PHP-5.6.31/ext/dom/document.c#L1590
[2] http://xmlsoft.org/html/libxml-tree.html#xmlParserCtxt

Wow!  I had no idea the PHP sources were up on github.  Thanx.  That's very helpful in figuring out whether something is a PHP bug or a libxml bug.  Thanx for the pointer.

I just found another case that muddies the waters with regards to what libxml considers a well-formedness error.

libxml_use_internal_errors( true );
libxml_clear_errors();
$dom = new DOMDocument();
$dom->loadXML( '<root xmlns:xml="urn:foo"/>' );
$errs = libxml_get_errors();
var_dump( $errs );

produces:

array(1) {
  [0]=>
  object(LibXMLError)#260 (6) {
    ["level"]=>
    int(2)
    ["code"]=>
    int(200)
    ["column"]=>
    int(16)
    ["message"]=>
    string(41) "xml namespace prefix mapped to wrong URI
"
    ["file"]=>
    string(0) ""
    ["line"]=>
    int(1)
  }
}

So, libxml doesn't consider that a "fatal" error even tho that instance is unambiguously not well-formed [1].

So, please leave this ticket open while I dig more into exactly what libxml does and does not consider to be a well-formedness error.

[1] https://www.w3.org/TR/REC-xml-names/#xmlReserved

I've seen enough of PHP's DOM code now that I believe any bugs found along these lines will not be with PHP itself. Which is to say, if there is such a bug (or other sort of incorrect or undesired behavior) then it would be in libxml.

We don't manage libxml, obviously, and we don't track their bugs. Just ours. And since PHP appears to be behaving correctly so far I'm going to leave this as NAB. If you find something that looks like a problem in PHP then I'll look too, but otherwise this bug tracker isn't really the best place to conduct a deep dive into libxml or how PHP interacts with it.
http://www.php.net/support.php