[Octave-bug-tracker] [bug #59245] Implementation of an XML interface without Java dependency

[Markus Mützel]

Update of bug #59245 (project octave):

                 Summary: Implementation of xmlread/xmlwrite without Java
dependency => Implementation of an XML interface without Java dependency

    _______________________________________________________

Follow-up Comment #5:

@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.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59245>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/