@becm:
Ping!

I've tried your regexp on a fair number of bug report spreadsheets and some of my own work collection and I see no regressions so I'm ready to push the fix.
But:
Would you like to be credited? in that case only your name and email address is required

If the non-greedy expression is not too much of a performance hit
it may be reasonable to make further changes (see `oct_regex.m`).

This will still not catch all the possible silliness, but at least:
- totally different attributes names just ending in 't'
- any stray 't' anywhere before the actual attribute.

Problem: Attribute values have less strict rules than XML data:
https://www.w3.org/TR/xml/#NT-AttValue

Only reliably excluded character seems to boil down to '<':
- still accepted as reference indicator: &
- inconclusive/alternate start and end: ' "

(file #56468)

Thanks becm for your feedback.

You're right with the '[^>]*' part, have you tried yourself?

AFAIK whitespace shouldn't matter unless between "". IIRC all regexps should be able to ignore themwhitespace between attributes. That said I've never met them in the wild. The OCT interface has been existing for some 15 years now and never had such issues.

'>' (and 4 other) characters are illegal anyway in XML.

As to malformed XML in general, I think trusting all SW out there writing spreadsheet XML to behave well, also has advantages: catering for and gracefully catching XML errors only takes expensive time, and reading spreadsheets this way is slow enough already.

If you care you can upload a better patch here ;-)

Try with attached __OCT_xlsx2oct__.m and report back, please.

To replace it, find where io package lives:
(in Octave)
cd (strrep (which ("oct2xls"), "oct2xls.m", "private"))

I just applied the following patch:

@@ -96,7 +96,7 @@

   ## Get cell addresses and contents of t=".." tags, "<f>", "<v>" and "<is>"
   ## nodes, optionally just placeholders
-  val = regexp (rawdata, '<c r="(\w+)"(?:[^t>]*(>)|(?:[^t>]*t="(\w+)")>)(?:<f.+?(?:</f>|/>))?(?:<v(?:[^>]*)>([^<]*)</v>|<is><t>([^<]*)</t></is>|<v/>([^<]*))', "tokens");
+  val = regexp (rawdata, '<c r="(\w+)"(?:[^t>]*(>)|(?:[^t>]*t="(\w+)".*?)>)(?:<f.+?(?:</f>|/>))?(?:<v(?:[^>]*)>([^<]*)</v>|<is><t>([^<]*)</t></is>|<v/>([^<]*))', "tokens");
   ## <inlineStr>: <is><t>(.*?)</t></is>  ## formula: <f>..</f>
   if (any (cellfun (@length, val) != 3))
     warning ("xls2oct: error reading data from sheet %d", wsh);

(i.e., just added '.*?' w/o quotes to the regexp)
but I'm not sure if this is the right thing to do.
The issue is that first of all, regexps aren't quite made for reading XML; up till now the OCT interface scripts relied on (nowhere documented but seemingly generally accepted) alphabetical order of XML node tags. The Apache POI folks apparently chose to break this habit with adding this "s=" tag; anytime they may "fix" that.
Maybe an additional "s=" clause has to inserted before the "t=" (type) tag, who knows.

So maybe in due time I'll ask again to try with another __OCT_xlsx2oct__.m version :-)

(file #56459)

(io maintainer here)

Yeah Apache Poi makes for many problems these days. I stopped updating the spreadsheet I/O functions for POI since a few years as with every new POI release new methods were invented and other required methods shifted around over several .jar files. It is a big PITA to track which .jars are needed for every new POI release.

Anyway, I second Andy's request:
Please put up a test case here. Reading your report, a sample .xlsx file created by Apache POI may suffice.

("Release" and "Status" fields updated)

Apache POI started to add a Style tag to cells: '<c ... s="...">'

As a result, cell content is not identified as such (empty sheet).

This now constitutes a "in the wild" issue as mentioned in
respective comment for regex call (for other tags).