On Sun, May 2, 2021 at 10:37 AM Paul Higgs <paul_hi...@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:bkl...@rksystems.com _______________________________________________ lxml - The Python XML Toolkit mailing list -- lxml@python.org To unsubscribe send an email to lxml-le...@python.org https://mail.python.org/mailman3/lists/lxml.python.org/ Member address: arch...@mail-archive.com
