3 ms·

I appreciate that Microsoft has taken to publishing their file format specifications, but what do you make of the changelog? It indicates to me that the format

by idm 11y ago

I appreciate that Microsoft has taken to publishing their file format specifications, but what do you make of the changelog? It indicates to me that the format itself is volatile, potentially changing multiple times per year. Further, the changelog highlights the proprietary nature of the format; Microsoft owns it and may change it at will. We have also been down this road before. Projects like LibreOffice/OpenOffice and pandoc have tried in earnest to match the specifications published by Microsoft, but it is always an imperfect implementation of either the reader or the writer. Because it seems to be virtually impossible, in practice, to implement Microsoft's document format specifications, I do not think the publication of the specifications alone makes a file format suitable for archival purposes.

WorldMaker 11y ago
I think the issue here is orthogonal end goals: 1. An organic/"rapidly" changing format does indeed make it harder to "keep up" if you are building a contemporary "competitor" application. 2. However, for archival purposes it shouldn't matter how rapidly/organically the specification changed in the lifetime of the document, so long as you have an adequate specification snapshot from somewhere around the last modified state of the document. (Or presuming, as you should be able to even with Microsoft's standards, a standard that maintains a heavy bias towards backwards compatibility in document reading, only the final specification.) Admittedly, we can't entirely anticipate the headaches of future cryptarchs, but an open specification I do feel is sufficient for archival purposes.
- idm 11y ago
  > we can't entirely anticipate the headaches of future cryptarchs First off, I love the term "cryptarch". :) That's basically the user we're talking about here. My concern is that archival media may become skewed from the media reader such that the media cannot be rendered with high fidelity (i.e. lossless). > so long as you have an adequate specification snapshot If the reader implementation itself has been lost to the ages, or perhaps the implementation is not runnable on contemporary hardware, then I worry that the specs alone may not be sufficient to reimplement the reader. > a standard that maintains a heavy bias towards backwards compatibility On the topic of archival, I'm concerned that ASCII will be a readable data format in 50 years. With that perspective, I am pretty skeptical that a spec as complex as the OneNote spec will maintain backward-compatible coherence across the same time span.
  - WorldMaker 11y ago
    «If the reader implementation itself has been lost to the ages, or perhaps the implementation is not runnable on contemporary hardware, then I worry that the specs alone may not be sufficient to reimplement the reader.» For archival on an apocalyptic scale, I don't expect future readers to read nor care at a high fidelity/"lossless" form of some of my documents. Certainly for my own notes to myself, I hope it is sufficient that future readers may get the gist of my scribblings from what they can scrounge out of a document based on specification snapshots (or even just scrounging for readable strings that seem vaguely Unicode like). I suppose there's an off chance I might do or say something that makes me a remarkable specimen to future histories and they may be interested in a deeper study of my works to the point of attempting high fidelity recreations, but I am alright with leaving that as an exercise to them. (Why spoil all their fun? :) «I'm concerned that ASCII will be a readable data format in 50 years.» A) I am amused and also not entirely surprised at such a pessimistic timescale. I'm not quite that pessimistic most days, but I can certainly see that perspective. B) I'd certainly like to hope that the efforts we've paid into Unicode will prevent future string data encoding wars and that ASCII will be seen as the degenerate form of Unicode that it is these days. I would hope that specification snapshots of Unicode should be sufficient to future programmers for millennia to come. C) In the event of such an apocalypse that even decoding ASCII (much less Unicode) is a huge endeavor, I fear that most hope is already lost, regardless of file format or media type... «First off, I love the term "cryptarch".» Indeed. One of the few things the videogame Destiny has managed to beneficially provide to our society is this little bit of useful jargon.
  - Ezhik 11y ago
    ASCII is simple enough to decode even without a computer, though.
brudgers 11y ago
I like open source software, but OpenOffice file formats were based on serving Sun's business interests in the same way that OpenDocument was based on serving Microsoft's. Microsoft developed OpenDocument because Sun's proposed standard did not support all the existing features in Microsoft's Office suite. Microsoft was faced with degrading features in an existing product or developing their own open standard or staying proprietary. As we've seen since Sun sold itself to Oracle, OpenOffice was a strategic move in the same way that Google's Docs were...the land of fat desktop apps just wasn't where the puck was going.

by idm 11y ago

WorldMaker 11y ago

I think the issue here is orthogonal end goals: 1. An organic/"rapidly" changing format does indeed make it harder to "keep up" if you are building a contemporary "competitor" application. 2. However, for archival purposes it shouldn't matter how rapidly/organically the specification changed in the lifetime of the document, so long as you have an adequate specification snapshot from somewhere around the last modified state of the document. (Or presuming, as you should be able to even with Microsoft's standards, a standard that maintains a heavy bias towards backwards compatibility in document reading, only the final specification.) Admittedly, we can't entirely anticipate the headaches of future cryptarchs, but an open specification I do feel is sufficient for archival purposes.

idm 11y ago
> we can't entirely anticipate the headaches of future cryptarchs First off, I love the term "cryptarch". :) That's basically the user we're talking about here. My concern is that archival media may become skewed from the media reader such that the media cannot be rendered with high fidelity (i.e. lossless). > so long as you have an adequate specification snapshot If the reader implementation itself has been lost to the ages, or perhaps the implementation is not runnable on contemporary hardware, then I worry that the specs alone may not be sufficient to reimplement the reader. > a standard that maintains a heavy bias towards backwards compatibility On the topic of archival, I'm concerned that ASCII will be a readable data format in 50 years. With that perspective, I am pretty skeptical that a spec as complex as the OneNote spec will maintain backward-compatible coherence across the same time span.
- WorldMaker 11y ago
  «If the reader implementation itself has been lost to the ages, or perhaps the implementation is not runnable on contemporary hardware, then I worry that the specs alone may not be sufficient to reimplement the reader.» For archival on an apocalyptic scale, I don't expect future readers to read nor care at a high fidelity/"lossless" form of some of my documents. Certainly for my own notes to myself, I hope it is sufficient that future readers may get the gist of my scribblings from what they can scrounge out of a document based on specification snapshots (or even just scrounging for readable strings that seem vaguely Unicode like). I suppose there's an off chance I might do or say something that makes me a remarkable specimen to future histories and they may be interested in a deeper study of my works to the point of attempting high fidelity recreations, but I am alright with leaving that as an exercise to them. (Why spoil all their fun? :) «I'm concerned that ASCII will be a readable data format in 50 years.» A) I am amused and also not entirely surprised at such a pessimistic timescale. I'm not quite that pessimistic most days, but I can certainly see that perspective. B) I'd certainly like to hope that the efforts we've paid into Unicode will prevent future string data encoding wars and that ASCII will be seen as the degenerate form of Unicode that it is these days. I would hope that specification snapshots of Unicode should be sufficient to future programmers for millennia to come. C) In the event of such an apocalypse that even decoding ASCII (much less Unicode) is a huge endeavor, I fear that most hope is already lost, regardless of file format or media type... «First off, I love the term "cryptarch".» Indeed. One of the few things the videogame Destiny has managed to beneficially provide to our society is this little bit of useful jargon.
- Ezhik 11y ago
  ASCII is simple enough to decode even without a computer, though.

brudgers 11y ago

I like open source software, but OpenOffice file formats were based on serving Sun's business interests in the same way that OpenDocument was based on serving Microsoft's. Microsoft developed OpenDocument because Sun's proposed standard did not support all the existing features in Microsoft's Office suite. Microsoft was faced with degrading features in an existing product or developing their own open standard or staying proprietary. As we've seen since Sun sold itself to Oracle, OpenOffice was a strategic move in the same way that Google's Docs were...the land of fat desktop apps just wasn't where the puck was going.