bug#4950: `xml-parse-file' returns incorrect results strings after `>' before `<' when CR\LF TAB+

bug#4950: `xml-parse-file' returns incorrect results strings after `>' before `<' when CR\LF TAB+

[MON KEY]

`xml-parse-file' returns incorrect results strings after `>' before
`<' when CR\LF TAB+

`xml-parse-file' fails to retrun correct results when there are ^C-j
(e.g. CR\LF)
followed by \t+ e.g TAB+ after a tag's trailing `>' and before the next tag's
leading `<'. IOW the following:

,----
| <ELEMENT attr1="a1" attr2="a2" attr3="a3" attr4="a4" attr5="a5">CR\LF
| TAB TAB TAB <NEXT-NODE>
`----

Returns (:NOTE with my pp-ing to help clarify the problem):

,----
| (ELEMENT nil
|          ((attr1 . "a1")
|           (attr2 . "a2")
|           (attr3 . "a3")
|           (attr4 . "a4")
|           (attr5 . "a5") "
|             " ;; <-i.e. (mapconcat #'char-to-string '(32 10 9 9 9) "")
|           (NEXT-NODE nil (...
`----

Is it if fair/safe to assume that where these types of sequences occur they are
not part of the XML and can be removed with a regexp? E.g. :

,----
| (while (search-forward-regexp "\"\)\n[\[:blank:]]+\"\)" nil t)
|        (replace-match ""))
`----

or perhaps:

,----
| (defun cln-xml<-parsed (fname &optional insertp intrp)
|   "Strip non-sensical strings created by xml-parse-file because of
| CR\LF TAB+ following tags/elements.
| FNAME is an XML filename path to parse and clean.
| When INSERTP is non-nil or called-interactively insert pretty printed lisp
| representation of XML file at point. Does not move point."
|   (interactive "fXML file to parse: \ni\np")
|   (let (get-xml)
|     (setq get-xml
|           (with-temp-buffer
|             (prin1 (xml-parse-file fname) (current-buffer))
|             (goto-char (point-min))
|             (while (search-forward-regexp
|                     "\\( \"\n[\[:blank:]]+\\)\"\\(\\(\\()\\)\\|\\(
(\\)\\)\\)" nil t)
|                    ;;^^1^^^^^^^^^^^^^^^^^^^^^^^^^2^^3^^^^^^^^^^^^4^^^^^^^^^^^^
|             (replace-match "\\2"))
|             (pp-buffer)
|             (buffer-substring-no-properties (point-min) (point-max))))
|     (if (or insertp intrp)
|         (save-excursion
|           (newline)
|           (princ get-xml (current-buffer)))
|         get-xml)))
`----

:SEE-ALSO
(URL `http://lists.gnu.org/archive/html/bug-gnu-emacs/2001-11/msg00052.html')

s_P

bug#4950: `xml-parse-file' returns incorrect results strings after `>' before `<' when CR\LF TAB+

[Chong Yidong]

MON KEY <monkey@sandpframing.com> writes:

> <ELEMENT attr1="a1" attr2="a2" attr3="a3" attr4="a4" attr5="a5">CR\LF
> TAB TAB TAB <NEXT-NODE>
>
> Returns (:NOTE with my pp-ing to help clarify the problem):
>
> (ELEMENT nil
>          ((attr1 . "a1")
>           (attr2 . "a2")
>           (attr3 . "a3")
>           (attr4 . "a4")
>           (attr5 . "a5") "
>             " ;; <-i.e. (mapconcat #'char-to-string '(32 10 9 9 9) "")
>           (NEXT-NODE nil (...
>
> Is it if fair/safe to assume that where these types of sequences occur
> they are not part of the XML and can be removed with a regexp?

No.

XML 1.0 Recommendation, Section 2.10 White Space Handling:

"An XML processor MUST always pass all characters in a document that are
not markup through to the application."