Re: Recent updates to I/O package xmlread API leave Matlab/Octave incompatible

[Pablo Mayrgundter]

Hey Philip,

Happy to help, though not sure how involved it is.  I see you're maintaining it, so maybe we can chat through a few patches?

I'd move the current xml{read,write} functions out entirely like I suggested and replace them with java-based handlers.  Does that sound like a good approach?

If so, next issue is that when I go to build packages, the Makefile in octave-forge/packages tries to fetch http://octave.sourceforge.net/packages.md5 which is 404.  It looks fairly important for the build versioning process.. any suggestion of how to proceed?

Cheers,
Pablo

On Wed, Apr 4, 2012 at 4:38 PM, PhilipNienhuis [via Octave] <[hidden email]> wrote:

Please report issues with octave-forge packages to the octave-forge mailing list:
https://lists.sourceforge.net/lists/listinfo/octave-dev

OK:

Pablo Mayrgundter wrote

Hi All,

First off, thanks for doing Octave dev work!  I just came across what I think is a recent Octave/Matlab incompatibility that I wanted to notify you about.

I just grabbed the io package from octave-forge and tried to use it to load some OSM data using the OSM Fuctions Matlab package:

  http://www.mathworks.com/matlabcentral/fileexchange/35819-openstreetmap-functions

But it failed, as the xmlread function in the current octave-forge package only loads a custom format XML that defines internal octave datatypes.  This looks to be a recent update by carandraug:

  http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/io/src/xmltree_read.l?revision=10145&view=markup

(search for "Bad declaration" to see that it's expecting an octave.dtd declaration, and will fail on generic XML)

Matlab's xmlread function, on the other hand, works for abritrary XML, by returning a DOM tree:

  http://www.mathworks.com/help/techdoc/ref/xmlread.html

Is this API divergence intentional?  It seems to me Octave's xmlread should behave like Matlab's, and the custom octave-xml code that's in there now should be moved to different naming, like octaveXmlRead or something.

Recently xmlread and xmlwrite have been moved from the miscellaneous pkg into the io pkg as io is a more logical home for them, but this move has little to do with a regression of "ML compatibility".
AFAIK the issue actually is that xmlread & xmlwrite are essentially as unmaintained as they have always been :-(  
Sorry for that.

I've looked at them two years ago to see if they might be used for ODS I/O, but it turned out they lacked even the most basic internal documentation. I couldn't even discern how they were to be used in practice, despite the suggestive texinfo help text.
But perhaps this is easily mended.

Could you fix them, please?

Philip

---

If you reply to this email, your message will be added to the discussion below:

http://octave.1599824.n4.nabble.com/Recent-updates-to-I-O-package-xmlread-API-leave-Matlab-Octave-incompatible-tp4532969p4533122.html

To unsubscribe from Recent updates to I/O package xmlread API leave Matlab/Octave incompatible, click here.
NAML

--

interweb homepage

---

View this message in context: Re: Recent updates to I/O package xmlread API leave Matlab/Octave incompatible
Sent from the Octave - General mailing list archive at Nabble.com.