4 ms·

> 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 idea

> 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?

JoshTriplett 11y ago
> 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.
- cwyers 11y ago
  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.
- throwawaykf05 11y ago
  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.

JoshTriplett 11y ago

> 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.

cwyers 11y ago
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.
throwawaykf05 11y ago
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.