![](https://secure.gravatar.com/avatar/1a2495493e0166d41f6cae64ed6f29ea.jpg?s=120&d=mm&r=g)
Thanks Bob, that’s much clearer Rather than the current error message of Element 'ProcessingStatusValue': [facet 'enumeration'] The value 'Processing complete' 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'}. You would rather see Element 'ProcessingStatusValue': [facet 'enumeration'] The value 'Processing complete' 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'}. for example. I know where this error message is being generated in libxml2 (in xmlschemas.c). If you could send a small XML instance and schema that fails, I can run the debugger against XMLint to understand the logic leading to this. It is probably an error in libxml2 rather than in in the lxml python bindings. Cheers Paul -----Original Message----- From: Bob Kline <bkline@rksystems.com> Sent: 02 May 2021 17:57 To: Paul Higgs <paul_higgs@hotmail.com> Cc: lxml mailing list <lxml@lxml.de> Subject: Re: [lxml] Tested value modified in validation error message On Sun, May 2, 2021 at 10:37 AM Paul Higgs <paul_higgs@hotmail.com> wrote:
If the input is "Processing\ncomplete" and the match string is "Processing complete" then this will not be a match, but if your enumeration value is "Pattern\scomplete" it should be OK (and it will also match "Pattern complete"(. (I guess the "sometimes garbles whitespace inside text nodes" is just the commercial XML editor wrapping lines that could exceed a 'pretty' length.
Hi, Paul. We're dealing with two bugs. The first bug is the behavior of the editor vendor's implementation of the DOM API, which is giving us back corrupted XML when we ask for the serialized document via the Document object's xml property. We know that it's the implementation of the serialization for that property which is introducing the corruption, rather than corruption of the values in the DOM itself, because when we recursively walk through all the nodes of the DOM to implement our own serialization of the document, the corruption is not present, and the whitespace inside all of the text nodes is intact. We have reported that problem to the editor vendor, and I have implemented a workaround to avoid this first bug. The bug I'm asking about in this forum is the second bug, which is producing an incorrect error message, pretending that the value being submitted for testing was "Processing complete" (without a newline character) when the value being tested was actually "Processing\ncomplete" (with a newline character). The confusion this misleading error message introduced made it much more difficult than it should have been to track down and identify the first bug. Does that make things clearer? -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com