![](https://secure.gravatar.com/avatar/367e3991e93e758afc2c45c52752958a.jpg?s=120&d=mm&r=g)
Well, we wouldn't need any modification to libxml2 to see the non-printable characters. We can use repr() for that. for error in schema.error_log: print(repr(error.message)) "Element 'root': [facet 'enumeration'] The value 'Processing\ncomplete' is not an element of the set {'Ready for English peer review', 'Ready for English scientific review', 'Ready for English OCCM review', 'Ready for Spanish peer review', 'Ready for Spanish OCCM review', 'Ready for publishing', 'Ready for translation', 'Processing complete'}." "Element 'root': 'Processing\ncomplete' is not a valid value of the local atomic type." Cheers, Bob On Mon, May 3, 2021 at 2:43 AM Paul Higgs <paul_higgs@hotmail.com> wrote:
Hi Bob
I'm glad you found a solution for your issue. I got stuck on a validation issue once which said "'<' expected" and there certainly was one - in the text editor, but in a binary file editor I could see a couple of non-printable characters.
It still strikes me as strange that an error message reading " 'a b' is not in the set {'a b', 'a c'} is somewhat misleading, so I did some debugging and found that right the way up to the call to vfprintf, the error message contains the '\n'. I will likely raise something on the libxml2 lists/issue tracker to see if there is a belief that non-printable characters should be converted when outputting an error message.
Paul -----Original Message----- From: Bob Kline <bkline@rksystems.com> Sent: 02 May 2021 20:24 To: Paul Higgs <paul_higgs@hotmail.com> Cc: Stefan Behnel <stefan_ml@behnel.de>; lxml@python.org Subject: Re: [lxml] Re: Tested value modified in validation error message
On Sun, May 2, 2021 at 1:45 PM Paul Higgs <paul_higgs@hotmail.com> wrote:
I just created the following ... I will look into the libxml2 to see where the \n is being converted to a <space>. ....
Actually, your repro case is showing the correct behavior. In other words, the \n is NOT being converted to a space character. I created a comparable repro case using lxml.etree, and observed the correct behavior there, as well. So I dug a little further, and found that the second bug is actually in our own code. So, I am suitably embarrassed, and I apologize for the wild goose chase. Thank you both for helping to nudge me back onto the path of truth. :-)
Regards, Bob
-- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com
-- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com