octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #59245] Implementation of an XML interface wit


From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #59245] Implementation of an XML interface without Java dependency
Date: Sat, 7 Nov 2020 15:29:21 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36 Edg/86.0.622.63

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

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)
    _______________________________________________________

Additional Item Attachment:

File name: bug59245_xmlread_xmlwrite_v2.patch Size:58 KB
   
<https://file.savannah.gnu.org/file/bug59245_xmlread_xmlwrite_v2.patch?file_id=50222>

File name: bug59245_readstruct.patch      Size:3 KB
   
<https://file.savannah.gnu.org/file/bug59245_readstruct.patch?file_id=50223>



    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]