Rustaceans at the border [LWN.net]

Rustaceans at the border

Posted Apr 20, 2022 3:48 UTC (Wed) by ssokolow (guest, #94568)
In reply to: Rustaceans at the border by zdzichu
Parent article: Rustaceans at the border

Are you really arguing in favour of less documentation?

The Andrew Schulman Programming Series ("Undocumented DOS", "DOS Internals", "The Undocumented PC", "Undocumented Windows", "Windows Internals", etc.) would like a word with you.

to post comments

Rustaceans at the border

Posted Apr 25, 2022 19:41 UTC (Mon) by flussence (guest, #85566) [Link] (4 responses)

And on the other end there's the OOXML specification...

Rustaceans at the border

Posted Apr 29, 2022 14:09 UTC (Fri) by ssokolow (guest, #94568) [Link] (3 responses)

The problem with the OOXML specification isn't over-documentation. It's rampant NIH combined with "Good time to clear out code debt? What's that?"

For example, the XLS to XLSX migration would have been a great time to ditch Excel 1.0's date format which assumes 1900 was a leap year. Instead, they baked it into XLSX.

Combine that with how OOXML embeds a million other things that ODF farms out to other specs (eg. SVG for vectors) and it's easy to see why OOXML is such a mess. They pushed a million implementation details of a legacy codebase into the spec document and then politicked it into being a "standard" to make it difficult for others to implement. (As I remember, they fronted the membership fees to get a bunch of their allies added to the voting body just in time for the vote.)

Rustaceans at the border

Posted Apr 29, 2022 16:00 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

> The problem with the OOXML specification isn't over-documentation.

As if "do X like Excel 2003 did" was anything but under-documentation.

Rustaceans at the border

Posted Apr 29, 2022 19:11 UTC (Fri) by ssokolow (guest, #94568) [Link]

If they have some of that, then that's also a problem. I was referring to how it's made needlessly difficult by things like these snips quoted from the post I linked:

For legacy reasons, an implementation using the 1900 date base system shall treat 1900 as though it was a leap year. [Note: That is, serial value 59 corresponds to February 28, and serial value 61 corresponds to March 1, the next day, allowing the (nonexistent) date February 29 to have the serial value 60. end note] A consequence of this is that for dates between January 1 and February 28, WEEKDAY shall return a value for the day immediately prior to the correct day, so that the (nonexistent) date February 29 has a day-of-the-week that immediately follows that of February 28, and immediately precedes that of March 1.

date1904 (Date 1904)

Specifies a boolean value that indicates whether the date systems used in the workbook starts in 1904.
A value of on, 1, or true indicates the date system starts in 1904.
A value of off, 0, or false indicates the workbook uses the 1900 date system, where 1/1/1900 is the first day in the system.
The default value for this attribute is false.

(That particular example is their "TIFF has little-endian and big-endian versions" moment. An XLSX file contains a flag that indicates whether the dates are serializations of Excel 1.0 for Windows's in-memory format or Excel 1.0 for Mac's in-memory format, which have different epochs and different bugs... because apparently, in true Microsoft fashion, they were made by different teams who at least didn't communicate and probably saw each other as competitors.)

Rustaceans at the border

Posted Apr 29, 2022 20:20 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

People keep referring to that, but in reality it's just a couple of relatively unimportant formatting directives that you can safely ignore in practice. OOXML is _really_ overspecified.