To check if the XML written by RapidXML is compatible with what Excel expects in .xlsx files, I read one sheet of a random .xlsx file and wrote it back.
The resulting file looks the same when opened in Excel afaics. That's not a conclusive test. But it gives hope that it might be possible to get it to work with something that is close to what is in the patch already.

To check if the functions that are implemented until now are sufficient to traverse the DOM tree and get the most important information, I tried to write a wrapper for `xmlread` that is more or less compatible to Matlab's `readstruct`. It turned out that some features were still missing.

The attached patches implement a more or less Matlab compatible `readstruct`. This is still a work in progress.
But the features of `xmlread` and `xmlwrite` that are needed for `readstruct` and `writestruct` are probably more or less what is needed for `readcell` and `writecell`. (The latter are probably a lot more complex though.)

My plan is to get skeleton versions of `readstruct` and `writestruct`. I hope that, writing those, it will be possible to detect and smooth out the roughest edges of `xmlread` and `xmlwrite`.
Maybe later on, those skeleton versions can be fleshed out and make their way into Octave.

For the proper goal of getting `readcell` and `writecell` for reading Excel files: I'll definitely need help for implementing those. I hope we can draw from the knowledge accumulated in the io package.
Maybe, we could try to implement those functions in .m files using `xmlread` and `xmlwrite` when they are ready. If it turns out that the performance cost for those interfaces is too high, we might be able to speed things up by getting more specialized interfaces to RapidXML. (But I'm getting ahead of myself...)

(file #50222, file #50223)

About error messages:
Excel may show file names and line numbers [*], but that is of little use in a long XML string of several tens-of-thousands or more characters - it'll be a long search.
LibreOffice is so nice to also tell you at what character position it encountered a problem.

[*] Excel 2013 and 2016 only tell me something along the lines of "We found a problem in <filename>. Delete content"?
Furthermore, are line numbers really useful? OOXML files usually consist of just two lines: Line 1 is the XML version header, line 2 contains all the actual XML content.

@Philip: Thank you very much for your feedback.
Could you please elaborate on what you think is bad about how RapidXML implements IO?
It takes a pointer to an array for input and writes to any string iterator. Imho, it is a plus point that it doesn't try to hide file IO in its API because that is bound to cause issues on some platforms (Windows, I am looking at you!). We have several wrappers in Octave already that handle the platform specific peculiarities...

Excel's error messages (including file names and line numbers) proved to be quite useful to identify the issue...

AFAICT, there is no XML standard that dictates or suggests order of sibling nodes. That must be OOXML specific.

I tried to read the xml of an .xlsx file with `readstruct` and write it again (without changing anything) with `writestruct`. There were issues writing the header (which are easy enough to work around).
I then zipped everything pack to an .xlsx file.
If I try to open the resulting file, Excel complains about invalid syntax.
The main issue seems to be that the order of tags seems to be important for OOXML. E.g. it looks like v-tags must not appear before f-tags. If I manually edit the xml to correct the order of these tags, Excel seems to be able to open the resulting file.

It looks like `readstruct` successively adds fields to the struct arrays while iterating through the DOM nodes. That means that the order of fields can differ from the one in the file if some tags don't exist in earlier nodes (see the attached screenshot).

This is probably what you were hinting at in comment #6.

I'm still debating how to proceed.
Maybe I shouldn't give up on xmlread/xmlwrite so quickly.
One possible strategy might be to rename them to oxmlread/oxmlwrite (to avoid having them shadowed by the functions in the io package which will always be more Matlab compatible). That way we could leave them deliberately incompatible where we don't need full compatibility.
We could also make them internal functions for the (not yet existing) readcell/writecell. But I guess they could come handy for end users, too.

Also, implementing readstruct/writestruct might still be worthwhile even if it won't be possible to use those functions for reading and writing OOXML...

I'll have to think about that. Input very welcome.

@Guillaume: I wasn't aware of these functions. Their interface looks much cleaner and "more native" than xmlread/xmlwrite.
For a test, I unzipped a random .xlsx file I had lying around and tried to read one of the worksheet .xml files in Matlab R2020b. It was successfully read into a (nested) structure that resembles the DOM tree of that file.
I wonder if working with these structures would cost performance as opposed to accessing the XML DOM tree more directly. But afaict, it might be possible to use these functions as intermediate layers for reading/writing .xlsx files.
Given that, I'll drop trying to implement xmlread/xmlwrite in favor of readstruct/writestruct.
I just wish I knew about these functions earlier...

@Philip: There are also readcell/writecell which work with cell arrays instead of tables. We might be able to implement those already. That could be done either in Octave language using readstruct/writestruct (if the performance penalty isn't too bad) or by accessing the XML DOM tree directly in C++. (Or maybe first implement it in Octave language to get the hierarchy sorted out and then translate that to C++ if necessary.)

AFAICT, the only XML "library" that core Octave is using already is QtXml. But Qt is an optional dependency (for the GUI and graphics toolkit). Additionally, QtXml isn't even mentioned as a contender in comparisons I found...
There might be different reasons why other software choses to use different XML libraries. But RapidXML seems to outperform libxml in comparisons (for XML it is able to read at least):
https://pugixml.org/benchmark.html

A nice decision tree with different XML parsers is e.g. here:
https://stackoverflow.com/questions/9387610/what-xml-parser-should-i-use-in-c

Also RapidXML seems to be stable and equally available on many distros.

I'd prefer to implement these features in incremental steps. Imho, we don't need to support .xlsx, .ods and .xls right from the start. Just one of them (.xlsx) would be better than none. If users want to read/write other formats, they will still be able to use the functions in the io package...

Being able to read "plain" XML would be a good initial step imho.

Some remarks, in no particular order:

In the mxe-octave installers there's libxml2 (and libxml++). Can that also be used? I suppose it's also in many Linux distros so if yes it may be a better library to use.

xmlread and xmlwrite are Java based and as such highly Matlab compatible.  I'd suppose many use cases and Matlab user code Out There are also Java based; could that compatibility be partly or wholly lost when switching to non-Java based parsers and other XML functions?

I'd support getting some form of xlsread and xlswrite into core Octave. Years ago JWE wrote that he also wanted it.
If this is done IMO it should read .xlsx, .ods and if possible, .xls (BIFF8 and/or BIFF5) as many embedded systems spew out .xls. Gnumeric is a very easy format so could also be included.

But writing .xlsx is a daunting task. The ECMA specs for the OOXML specs comprise thick tomes and to further put you off I'd suggest to read e.g., this:
http://ooxmlisdefectivebydesign.blogspot.com/2007/08/microsoft-office-xml-formats-defective.html   (hmm yet I found many useful hints in there :-) )
That said, .ods is even more complicated to handle with many implicit rules and no address in spreadsheet cell nodes.
In the io package OOXML and ODS formats have already been sorted out (many corner cases excluded) so that could serve for a start.

Matlab these days has readtable and writetable that can read from and write to spreadsheets. Their interface / calling form looks much more practical than the xlsread/xlswrite requirements of fixed but inconsistent argument order.
To implement readtable and writetable Octave needs the Table class. Andrew Janke has made Tablicious and on the task tracker there's a task for Table I/O based on the io package (task #15419)

@gyom:
readstruct doesn't look like it can read a spreadsheet file, can it?

Attached the patch.

I only tested it with toy examples. A better test would be to try if they work for reading and writing .xlsx files.
Is that possible at all or are there missing features?
How do the functions perform?

(file #49955)