You have to locate the sheet files. Sheet1.xml in this case.
You can find the strings, or more accurately, formulas (<f></f>) and their values (<v></v>) in these files and you can edit them. Excel fights this, you cannot change the files from read-only to not, so you have to save elsewhere and copy over the originals. Further, there will some subtle problems, apparently, aaaaand Excel will carp about opening the file, but it WILL open.
For fun, you can leave the value strings as is and they will show the wrong results for the modified formulas upon opening. The first recalc will fix them, of course, but it shows Excel does NOT recalc on open, just reads the saved material, including formula results. Not sure that could ever be useful, but... it's interesting.
Hmm... one thing I found was that one of the other files in the package contains absolute addressing for certain things. So if your company assigns user names, network access, and so on (login name for Windows, lots of "so on" here), it will BE in the absolute path for most peoples' setups. Who shifts their work to store on their C drive rather than a network share? Even with author/ownership properties cleared, these paths show enough to mark the casual user. If your Windows login is "TMashad", then these absolute paths will contain that and how hard would it be for someone to work with? Though who'd want to? I hope.
Eh... might've wandered from the point a tad. Sheet1.xml is what you want for editing strings and such. My guess was that what you were looking at, which I did not see, so it remains a guess, is OUTPUT, so it doesn't flow away to the strings themselves, but rather the flow is the opposite direction, INTO what you saw. Into only.
Still, interesting. I never really thought about how a lot of actually interesting material was hidden in the XML package...
