chore(xmlupload): improve parse xml function

[Nora-Olivia-Ammann]

Currently for the validate xml, the comments were not removed. This caused problems when finding the encodings attributes. However, we need the namespaces for the first validation step. Therefore a function was created that only parses the file and removes the comments.

[jnussbaum]

Now we have 2 functions that almost do the same:

• parse_and_remove_comments_xml_file()
• parse_and_clean_xml_file()

This is confusing, because it is almost duplicating things, but with slight deviations. This makes it very hard to understand the paths that the program can take.

These code paths should be disentangled.

[Nora-Olivia-Ammann]

Now we have 2 functions that almost do the same:

* `parse_and_remove_comments_xml_file()`

* `parse_and_clean_xml_file()`

This is confusing, because it is almost duplicating things, but with slight deviations. This makes it very hard to understand the paths that the program can take.

These code paths should be disentangled.

I agree, the reason why I did not do this here is because it opens a typing can of worms. If you would like to combine the functions, I am happy to do that, but I suggest another PR for that.

[jnussbaum]

Now we have 2 functions that almost do the same:

* `parse_and_remove_comments_xml_file()`

* `parse_and_clean_xml_file()`

This is confusing, because it is almost duplicating things, but with slight deviations. This makes it very hard to understand the paths that the program can take.
These code paths should be disentangled.

I agree, the reason why I did not do this here is because it opens a typing can of worms. If you would like to combine the functions, I am happy to do that, but I suggest another PR for that.

Why would you like to do it in another PR? AFAIU, you introduced the duplication in the present PR. It doesn't seem natural to me to introduce a duplication/bad architecture in one PR, and then schedule a follow-up PR...?

[Nora-Olivia-Ammann]

Now we have 2 functions that almost do the same:

* `parse_and_remove_comments_xml_file()`

* `parse_and_clean_xml_file()`

This is confusing, because it is almost duplicating things, but with slight deviations. This makes it very hard to understand the paths that the program can take.
These code paths should be disentangled.

I agree, the reason why I did not do this here is because it opens a typing can of worms. If you would like to combine the functions, I am happy to do that, but I suggest another PR for that.

Why would you like to do it in another PR? AFAIU, you introduced the duplication in the present PR. It doesn't seem natural to me to introduce a duplication/bad architecture in one PR, and then schedule a follow-up PR...?

Because I wanted to focus on PR that introduces the new feature and this stood in the way. But if it is a deal-breaker, then I can do it here.