> the "standardization" process itself was effectively politics, not technology.
All standardization processes are politics, pretty much by definition; defining a spec is technical, agreeing to a standard is political.
Not to say that the standardization of OOXML wasn't a particularly bad outcome, but "bad" vs. "good" is a different distinction than "politics" vs. "technical".
> By contrast, there are multiple independent implementations of ODF.
IIRC, OOXML is implemented by OOo/LO and Google Docs as well as Microsoft Office, the former two are independent implementations from the latter, if not also from each other. (I'm not sure any of those implementations are bug-free as compared to anything that has been standardized, much less fully compatible with each other -- ISTR even the Microsoft one early on had significant reported divergences from the standard.)
> All standardization processes are politics, pretty much by definition; defining a spec is technical, agreeing to a standard is political.
Little to no "defining" went on in the OOXML process, hence my use of the phrase "rubber-stamped". What little did take place seems to have been limited to adding more documentation for dangling references to undocumented bits, such as some of the "compatibility" options.
And no, there should be no "politics" in the agreement to a standard. The standard should be seeking the best solution to a problem, not the one best aligned with any particular party's best interests. No "I'll compromise on this if you compromise on that". And certainly no "let's make sure the people who would be inclined to say no don't get invited". OOXML wasn't just politics, it was dirty politics.
> Little to no "defining" went on in the OOXML process
Yeah, defining a spec often happens outside of, and prior to standardization (refinement of the definition may or may not happen during a standardization process.) A standardization process with little defining can be bad or good, depending on why there is little defining.
> And no, there should be no "politics" in the agreement to a standard. The standard should be seeking the best solution to a problem
"Best" is subjective, and involves balancing concerns which different parties will weigh differently; producing a consensus on that is inherently a political process.
> OOXML wasn't just politics, it was dirty politics.
> The standard should be seeking the best solution to a problem, not the one best aligned with any particular party's best interests.
1. That is a rather idealistic view of the world. Standards are typically set by committees comprised of multiple parties, and all entities have an agenda. Sometimes its self-interest, sometimes it's just something like "all things being equal, we prefer doing things this way", but it undoubtedly influences the outcome.
2. Regarding OOXML, maybe the actual problem could be stated as, "the vast majority of the world's official documentation is in a proprietary format and we want to make it open in a way that doesn't inconvenience the millions of users of the existing files, because otherwise nobody would use the new format." Regardless of whether there were dirty politics, what would the best solution to that look like?
> 1. That is a rather idealistic view of the world. Standards are typically set by committees comprised of multiple parties, and all entities have an agenda. Sometimes its self-interest, sometimes it's just something like "all things being equal, we prefer doing things this way", but it undoubtedly influences the outcome.
Certainly; however, making any such change needs to come with arguments that convince others and drive towards consensus, rather than political machinations to manufacture consensus.
When someone proposes a change software project, they doubtless have some reason for proposing that change. However, projects don't typically pay attention to reasons like "we need this change to support our product", or "this makes our internal processes easier", or "without this change our business model collapses". And they certainly don't accept arguments like "if you ignore what's wrong with this patch, I'll [insert reciprocation here]". A change has to come with arguments for why it's the right thing for the project, not just why it's the right thing for the person proposing the patch.
> 2. Regarding OOXML, maybe the actual problem could be stated as, "the vast majority of the world's official documentation is in a proprietary format and we want to make it open in a way that doesn't inconvenience the millions of users of the existing files, because otherwise nobody would use the new format." Regardless of whether there were dirty politics, what would the best solution to that look like?
Treat the old binary document format and representation as the legacy format it was, without giving it a veneer of "standardization". Add features and capabilities to the existing ODF standard, rather than creating a new competing one; likewise, in the various sub-formats, pay attention to existing standards rather than inventing new ones. Migrate to that format as the native format, not just as an export mechanism. Discourage people from saving in the old binary formats. Provide the rendering engine and parsing code of the old office suite as an Open Source library to handle legacy documents. Provide migration tools that actually cross-check things like pagination with the legacy document renderer, to confirm the fidelity of the conversion; collaboratively improve those tools until they achieve maximum fidelity on all available documents. Then, people can migrate new or edited documents with reasonable fidelity, get perfect fidelity for historical documents, and interchange documents with no compatibility issues.
That would not necessarily serve the goals of any one office suite vendor, but it would help move the world's documents to an open, standard, interchangeable format.
Regarding 1), again that is how things should be, and to people's credit, they make fair attempts towards it. But the real world is messy. As an example, very frequently there are a number of ways to achieve similar results. Then often the argument becomes "why's your way better than mine"? Each party prefers a certain approach because it's better for them
for whatever reason. Hence a compromise must be reached, and this is where the wheeling and dealing begins. This is just one of many reasons why, as dragonwriter said, this becomes a political process.
While the solution you propose for 2) makes perfect technical sense, I'd say it steps too much into "inconveniencing millions of users" territory. Providing tools for migration and checking fidelity are big pain points because it does not fit into their usual workflow, which alone makes it highly unlikely to be adopted. If you wanted people to have minimum disruption, the new format would have to be a completely compliant reimplementation of the old one, and I'd guess it's inevitable that the new standard would look exactly like the old one simply because it's the path of least resistance.
The ODF standard was based off the StarOffice file format. If anyone involved wanted Microsoft to participate, that seems like a rather poor starting point.
All standardization processes are politics, pretty much by definition; defining a spec is technical, agreeing to a standard is political.
Not to say that the standardization of OOXML wasn't a particularly bad outcome, but "bad" vs. "good" is a different distinction than "politics" vs. "technical".
> By contrast, there are multiple independent implementations of ODF.
IIRC, OOXML is implemented by OOo/LO and Google Docs as well as Microsoft Office, the former two are independent implementations from the latter, if not also from each other. (I'm not sure any of those implementations are bug-free as compared to anything that has been standardized, much less fully compatible with each other -- ISTR even the Microsoft one early on had significant reported divergences from the standard.)