[wb_load] read x namespace

[JanMarvin]

allow reading files with x namespace

what was the motivation for this PR?

This fixes import for files created by third party software as seen in ycphs/openxlsx#344.

Maybe one of you can test this @Matpli, @elinw? You can build this branch using:

remotes::install_github("JanMarvin/openxlsx2", ref = "gh_issue_213")

what does this PR do?

I have taken the initial #213 and created a few more safeguards to make sure that we do not have to check every xml file we import.

1. Instead now we only check if we find x:workbook in /xl/workbook.xml
2. If TRUE set options("openxlsx2.has_x_namespace" = TRUE)
3. If this option is true we read the file into R
4. If this string is found xmlns:x="http://schemas.openxmlformats.org/spreadsheetml/2006/main", we will remove the x namespace from the input
5. We let the user know that this is somewhat experimental and largely untested

It works with the example file provided by @Matpli and if I save this file I can open it in MS365. But this file is quite large so if anyone can provide a smaller example file, that would be great.

[jmbarbone]

Adding in some information what the x namespace is could be helpful when people counter this. I don't know what it is or any of the implications of changing these values are, so I'd certainly be confused.

[JanMarvin]

Adding in some information what the x namespace is could be helpful when people counter this. I don't know what it is or any of the implications of changing these values are, so I'd certainly be confused.

The example file used in the test wraps main in this x namespace: xmlns:x="http://schemas.openxmlformats.org/spreadsheetml/2006/main". Therefore all xml nodes are wrapped in this namespace. We - and Excel and every other spreadsheet software I'm aware of - use xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" therefore we do not need a namespace prefix.

Our xml nodes look like this <workbook> and in the example file they look like this <x:workbook>. But xml_node("<x:workbook/>", "workbook") will not return the expected result. Once we remove the x namespace from the nodes, we can read the file. Therefore this PR should be safe when importing with x namespace. However, since we are changing the xml files before importing and we currently only have this one file to test, I wanted to be careful.

In theory this namespace does not have to be named x and could be something else, though I didn't really want to search for other namespaces. In openxml there are various namespaces like x14 therefore assuming that it will be x should be safe. It is also mentioned in ECMA-376 Part 1: Annex D. Namespace Prefix Mapping in Examples.

[JanMarvin]

The more general fix would be to read the header and replace the namespace whenever they are found.

But I wanted something that works quick and does not interfere with the overwhelming majority of files we import. If we get reports that users experience plenty of these warnings, we can have a look at the c++ loading functions of pugixml and see if we can implement a remove namespace wrapper there.

[jmbarbone]

In theory this namespace does not have to be named x and could be something else, though I didn't really want to search for other namespaces. In openxml there are various namespaces like x14 therefore assuming that it will be x should be safe. It is also mentioned in ECMA-376 Part 1: Annex D. Namespace Prefix Mapping in Examples.

Maybe we can then use the options like:

options(openxlsx2.xml_namespace = "x") # maybe `TRUE` defaults to `"x"`?

or

options(openxlsx2.xml_namespace = c("foo", "bar")))

then check to see if any have been specified?

[jmbarbone]

From some quick searches this morning it sounds like the default x namespace can be particular annoying and prevent other software from correctly parsing the xml. It seems the go-to move is to remove the namespaces, so us doing it sounds right, especially if it's something the user has to opt into.

[JanMarvin]

Haha, mate don't make this overly complicated for us. But your suggestions sound reasonable, I'll adjust the PR later.

[JanMarvin]

Should be good to go now.