Bug #74988 [Opn->Nab]: DOMDocument::load() reports success but libxml_get_errors() return errors
| From: | requinix@php.net | Date: | Tue, 25 Jul 2017 21:49:18 +0000 |
| Subject: | Bug #74988 [Opn->Nab]: DOMDocument::load() reports success but libxml_get_errors() return errors | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-210330@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=74988&edit=1
ID: 74988
Updated by: requinix@php.net
Reported by: paul at sparrowhawkcomputing dot com
Summary: DOMDocument::load() reports success but
libxml_get_errors() return errors
-Status: Open
+Status: Not a bug
Type: Bug
Package: DOM XML related
Operating System: Windows 10 Pro
PHP Version: 5.6.31
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2017-07-25 21:09:49] paul at sparrowhawkcomputing dot com
Description:
------------
Given the following XML document in test.xml:
<?xml version="1.0"?>
<root xml:space='foo'/>
The script in the "Test Script" field below reports that the instance is loaded
successfully while simultaneously reporting well-formedness errors.
How can this instance be successfully loaded while there are well-formedness errors reported?
Test script:
---------------
libxml_use_internal_errors( true );
$dom = new DOMDocument();
libxml_clear_errors();
$success = $dom->load( __DIR__ . '/test.xml' );
$xml = $dom->saveXML();
$errs = libxml_get_errors();
var_dump( $success );
var_dump( $errs );
var_dump( $xml );
Expected result:
----------------
Either:
$success == false && ! empty( $errs ) && $xml === '<?xml
version="1.0"?>'
or
$success == true && empty( $errs ) && $xml === '<?xml
version="1.0"?>
<root/>
'
That is, if libxml_get_errors() is going to return errors then DOMDocument::load() should return
false. If DOMDocument::load() is going to succeed, then @xml:space should be ignored and
libxml_clear_errors() should be called internally before DOMDocument::load() returns.
Either alternative conforms to the XML spec, which says [1]:
This specification does not give meaning to any value of xml:space other
than "default" and "preserve". It is an error for other values to be
specified; the XML processor may report the error or may recover by ignoring
the attribute specification or by reporting the (erroneous) value to the
application. Applications may ignore or reject erroneous values.
The status quo does not conform to the XML spec because it both reports the error and fails to
ignore the @xml:space attribute.
I VERY MUCH prefer the first alternative, as it is consistent with XMLReader which correctly reports
the well-formedness error and refuses to parse test.xml.
[1] https://www.w3.org/TR/REC-xml/#sec-white-space
Actual result:
--------------
bool(true)
array(1) {
[0]=>
object(LibXMLError)#260 (6) {
["level"]=>
int(1)
["code"]=>
int(102)
["column"]=>
int(16)
["message"]=>
string(69) "Invalid value "foo" for xml:space : "default" or
"preserve" expected
"
["file"]=>
string(87) "file://test.xml"
["line"]=>
int(2)
}
}
string(80) "<?xml version="1.0"?>
<root xml:space="foo"/>
"
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=74988&edit=1