[iacvlvs]

I've worked with worse:

  <PERSON>
    <PERSON_HEADER_1>
      <PERSON_HEADER_1_NAME>
        <PERSON_HEADER_1_NAME_FIRST_NAME>John</PERSON_HEADER_1_NAME_FIRST_NAME>
        <PERSON_HEADER_1_NAME_LAST_NAME>Smith</PERSON_HEADER_1_NAME_LAST_NAME>
      </PERSON_HEADER_1_NAME>
      <PERSON_HEADER_1_ADDRESS>
        <PERSON_HEADER_1_ADDRESS_1>123 Some Street</PERSON_HEADER_1_ADDRESS_1>
        <PERSON_HEADER_1_ADDRESS_2>Blah</PERSON_HEADER_1_ADDRESS_2>
        <PERSON_HEADER_1_ADDRESS_3>Blah</PERSON_HEADER_1_ADDRESS_3>
        <PERSON_HEADER_1_ADDRESS_4>Blah</PERSON_HEADER_1_ADDRESS_4>
      </PERSON_HEADER_1_ADDRESS>

... and so on. I can't think of any advantage to (or excuse for) doing it this way. The only possible reason for it that I can think of, is rather comprehensive ignorance of how XML and related standards work.

[kalleboo]

It looks like it was written by someone who wanted to parse their XML using regexps instead of a real parser.

[MatthewPhillips]

I can top this; I once worked with an api that returned XML with 1 node that contained a string of more XML.

[thwarted]

The apache module that provides the gateway to Ecometry? That thing was a bear. I can't believe they did all the processing in the apache module rather than with a CGI.

It didn't actually use regular expressions, but parsed the input with a lot of char pointer manipulation.

The reason it worked like this was to have the "XML" tags map directly to the terminal input screens run on the backend, because it essentially input data as if a human was typing it into the terminal and navigating the forms.

I keep meaning to write this up as the worst example of XML abuse I've ever seen; I'm actually surprised someone else here has used the same thing (or even more surprised that more than one party has implemented the same braindead thing).

[neovive]

I have to work with MB's of this type of XML. It forces the use of special XML tools to even make is readable.