6329 2008-12-22 14:14:40 +0000 Implement XML::LibXML Structured Errors 2009-03-13 14:59:08 +0000 1 1 1 Unclassified Validator check HEAD All All RESOLVED FIXED http://deeden.co.uk/misc/quantum.html P2 normal --- 1 srushe ot ot www-validator-cvs oldest_to_newest 22822 0 srushe 2008-12-22 14:14:40 +0000 I've noticed that some pages are reporting valid at one point in time and invalid later despite nothing in the page having changed. This occurs with 3 or 4 pages I'm testing, all of which are presumably invalid with a common error (no space before a class=). I've reduced this down to a test case which reproduces the bug I'm seeing (http://deeden.co.uk/misc/quantum.html). There is no space before class="hello" on line 10 and this is what the validator reports on when it views the page as invalid. As I write this the page is being reported as invalid, however in a while (whether minutes or hours) it will report it as valid. If I retry the page a few times it will continue to say it is valid until it eventually starts reporting it as invalid, again consistently. I've checked that the headers being sent for the page are the same during both valid and invalid periods and they are, so it's not something to do with that. The behaviour I see is happening both through the web interface and the WebService::Validator::HTML::W3C perl module. 22823 1 ot 2008-12-22 14:26:39 +0000 (In reply to comment #0) > I've noticed that some pages are reporting valid at one point in time and > invalid later despite nothing in the page having changed. I find this surprising. One way to debug this would be to check “show source” in the validator and see if the validator is consistently served the same markup, or not. If the validator consistently received the same markup and reports different results, then it's a bug with the validator. If the validator receives different markup at different times, it is more likely to be an issue with your server, some proxy/cache at your ISP level, etc. I have loaded the validation results and will keep reloading to see if the results change. So far, results have been consistent (invalid). 22824 2 srushe 2008-12-22 14:54:01 +0000 (In reply to comment #1) > I find this surprising. One way to debug this would be to check “show source” > in the validator and see if the validator is consistently served the same > markup, or not. I knew there was one other thing I meant to check systematically. I did do this a quick check yesterday. Both the valid and invalid versions showed the same code in the source view. > I have loaded the validation results and will keep reloading to see if the > results change. So far, results have been consistent (invalid). It was the same here until just now when I checked. At the moment, it's reporting as valid for me. 22825 3 ot 2008-12-22 15:08:37 +0000 (In reply to comment #2) > It was the same here until just now when I checked. At the moment, it's > reporting as valid for me. Ack. It's not one validator being inconsistent, it's two servers acting differently: http://128.30.52.13/check?uri=http%3A%2F%2Fdeeden.co.uk%2Fmisc%2Fquantum.html&debug http://128.30.52.49/check?uri=http%3A%2F%2Fdeeden.co.uk%2Fmisc%2Fquantum.html&debug It looks like these two servers are using different versions of the XML libraries, but the difference in result are disturbing. Will look into that. 22830 4 srushe 2008-12-22 15:38:16 +0000 (In reply to comment #3) > > Ack. It's not one validator being inconsistent, it's two servers acting > differently: > http://128.30.52.13/check?uri=http%3A%2F%2Fdeeden.co.uk%2Fmisc%2Fquantum.html&debug > > http://128.30.52.49/check?uri=http%3A%2F%2Fdeeden.co.uk%2Fmisc%2Fquantum.html&debug > > It looks like these two servers are using different versions of the XML > libraries, but the difference in result are disturbing. Will look into that. Cheers for that Olivier. I'm relieved that it's not something I did. 22834 5 ot 2008-12-22 16:39:43 +0000 I am finding incompatibilities between libxml2 and XML::LibXML, two lower-lever libraries used by the validators, but only for certain versions. This is very puzzling, to say the least. Below, the script I used to test on various machines, and a number of results. The results saying "attributes construct error" are the proper, expected ones. I will try and contact the maintainer(s) for XML::LibXML, in hope that they can be of help. #!/usr/bin/perl use 5.008; use strict; use warnings; use utf8; use XML::LibXML qw(); my $dotted=XML::LibXML::LIBXML_DOTTED_VERSION; print "XML::LibXML Version: $XML::LibXML::VERSION\nlibxml2 Version: $dotted\n\n"; XML::LibXML->new()->parse_string('<foo attr1="value1"attr2="value2" />'); XML::LibXML Version: 1.66 libxml2 Version: 2.6.16 :1: parser error : attributes construct error <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Couldn't find end of Start Tag foo line 1 <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Extra content at the end of the document <foo attr1="value1"attr2="value2" /> ^ at testlibxml.pl line 5 ************************************************************************** XML::LibXML Version: 1.68 libxml2 Version: 2.6.16 :1: parser error : attributes construct error <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Couldn't find end of Start Tag foo line 1 <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Extra content at the end of the document <foo attr1="value1"attr2="value2" /> ^ at testlibxml.pl line 5 ************************************************************************** XML::LibXML Version: 1.69 libxml2 Version: 2.6.16 :1: parser error : attributes construct error <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Couldn't find end of Start Tag foo line 1 <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Extra content at the end of the document <foo attr1="value1"attr2="value2" /> ^ at testlibxml.pl line 5 ************************************************************************** XML::LibXML Version: 1.66 libxml2 Version: 2.6.32 :1: parser error : attributes construct error <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Couldn't find end of Start Tag foo line 1 <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Extra content at the end of the document <foo attr1="value1"attr2="value2" /> ^ at testlibxml.pl line 5 ************************************************************************** XML::LibXML Version: 1.69 libxml2 Version: 2.6.32 :1: parser error : Extra content at the end of the document ************************************************************************** XML::LibXML Version: 1.63 libxml2 Version: 2.6.29 :1: parser error : attributes construct error <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Couldn't find end of Start Tag foo line 1 <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Extra content at the end of the document <foo attr1="value1"attr2="value2" /> ^ at testlibxml.pl line 5 ************************************************************************** XML::LibXML Version: 1.68 libxml2 Version: 2.6.27 :1: parser error : Extra content at the end of the document ************************************************************************** 22835 6 ot 2008-12-22 16:40:14 +0000 (In reply to comment #4) > Cheers for that Olivier. I'm relieved that it's not something I did. No problem Steve, and many thanks for the report. 22836 7 ot 2008-12-22 16:52:08 +0000 For the time being I have downgraded the version of the XML::LibXML library (now using 1.66 which seems to work better) and the two validator.w3.org servers are producing the proper (and consistent) output. Will keep thi sbug open until we have a satisfying resolution of the library problem, not just this workaround. 22838 8 ot 2008-12-22 19:37:30 +0000 I think I found the culprit in the Changelog for XML::LibXML. In recent versions, there is a new module to use the Structured Errors API (great!) but it's not quite backward compatible. Will have to add code to handle the Structured Errors. http://search.cpan.org/~pajas/XML-LibXML-1.69/lib/XML/LibXML/Error.pod 22871 9 ot 2008-12-31 20:36:49 +0000 (In reply to comment #8) > I think I found the culprit in the Changelog for XML::LibXML. In recent > versions, there is a new module to use the Structured Errors API (great!) but > it's not quite backward compatible. > > Will have to add code to handle the Structured Errors. > http://search.cpan.org/~pajas/XML-LibXML-1.69/lib/XML/LibXML/Error.pod The frustrating part so far is that the new structured errors code only gives you the last parsing error (when, if anything, I would be happy enough showing only the first!) Using this code, from the perl module documentation: use 5.008; use strict; use warnings; use utf8; use XML::LibXML qw(); my $dotted=XML::LibXML::LIBXML_DOTTED_VERSION; print "XML::LibXML Version: $XML::LibXML::VERSION\nlibxml2 Version: $dotted\n\n"; eval {XML::LibXML->new()->parse_string('<foo attr1="value1"attr2="value2" />')}; if (ref($@)) { # handle a structured error (XML::LibXML::Error object) print $@->dump(); } elsif ($@) { # error, but not an XML::LibXML::Error object print $@; } else { # no error } ot@qa:~$ perl testlibxml.pl XML::LibXML Version: 1.66 libxml2 Version: 2.6.32 :1: parser error : attributes construct error <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Couldn't find end of Start Tag foo line 1 <foo attr1="value1"attr2="value2" /> ^ :1: parser error : Extra content at the end of the document <foo attr1="value1"attr2="value2" /> ^ at testlibxml.pl line 6 ot@qa:~$ perl testlibxml.pl XML::LibXML Version: 1.69 libxml2 Version: 2.6.32 $error = bless( { 'num1' => 0, 'file' => '', 'message' => 'Extra content at the end of the document ', 'domain' => 1, 'level' => 3, 'str2' => undef, '_prev' => undef, 'str1' => undef, 'str3' => undef, 'num2' => 11, 'code' => 5, 'line' => 1 }, 'XML::LibXML::Error' ); Maybe I'm doing it wrong? The documentation is scarce, might need to contact the developer(s) to get some clearer answers. 22980 10 ot 2009-01-07 22:06:45 +0000 Followup archived here: http://lists.w3.org/Archives/Public/public-qa-dev/2009Jan/0003.html Hoping Petr will have time to respond. 23225 11 ot 2009-01-22 14:34:57 +0000 Got a prompt reply from Petr: http://lists.w3.org/Archives/Public/public-qa-dev/2009Jan/0004.html and now waiting for the release of the version 1.70 of XML::LibXML http://search.cpan.org/dist/XML-LibXML/ Things are going to be tricky then, because any system with a version of XML::LibXML between 1.67 and 1.69 (inclusive) will have slightly wrong error reporting for xml-wf issues. I'm wondering whether this would be acceptable, or whether to require >= 1.70, which may then be a burden. To be continued... 23400 12 ot 2009-02-02 23:20:42 +0000 *** Bug 4420 has been marked as a duplicate of this bug. *** 23479 13 ot 2009-02-05 17:02:47 +0000 Ah-ha! XML-LibXML-1.69_1 developer release. Should be enough to start work on implementing the structured errors in the validator. http://cpansearch.perl.org/src/PAJAS/XML-LibXML-1.69_1/Changes 23713 14 ot 2009-02-13 15:05:39 +0000 Implementation done, ready for next release: http://lists.w3.org/Archives/Public/www-validator-cvs/2009Feb/0092.html and http://lists.w3.org/Archives/Public/www-validator-cvs/2009Feb/0136.html Note that the code above does rely on a developer version of XML::LibXML - might be a bit of trouble for people with their own instance. But with time, we'll be fine. 24231 15 ot 2009-03-13 14:59:08 +0000 Here is a one liner to text which version of XML::LibXML your system has: perl -MXML::LibXML -e 'print " XML::LibXML Version: $XML::LibXML::VERSION\n";' If you have a version > 1.66 and < 1.70, I suggest heading to CPAN and install the latest version: http://search.cpan.org/dist/XML-LibXML/