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

[Markus Mützel]

Follow-up Comment #7, bug #59245 (project octave):

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.


(file #49958)
    _______________________________________________________

Additional Item Attachment:

File name: readstruct_fieldorder.PNG      Size:14 KB
   
<https://file.savannah.gnu.org/file/readstruct_fieldorder.PNG?file_id=49958>



    _______________________________________________________

Reply to this item at:

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

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