Where, precisely, did he say he was using Linux as the client? He didn't, he said Linux as the backup server. And BackupPC seem sto be more oriented towards Windows backups since it uses SMB rather than NFS for it's backups.
Nice rant, but you seem to be ranting about something that wasn't even implied in the original message.
Actually, it's a little bit more than that. For example, you can completely restore a PC, like if you had use Ghost, but at the same time it gives you full access to the files as if you used a file backup. What's more, it consolidates duplicate files in the backups so that they don't take up extra space.
You can also add storage to the thing just by dropping in a new disk and telling it to use it. No re-partitioning, or mounting partitions in subfolders. it spans drives and provides automatic redundancy without RAID and the associated probles with adding new storge to RAID volumes.
It also has a neat "plug-in" feature that allows third parties to extend it. Here's some examples:
Not exactly. You're confusing file sharing with backups. The problem occurs when you edit a file that is stored on the Windows Server file shares, the backup of the file on the file share may become corrupt. However, files backed up via the backup agent from your local computer are not corrupted when you edit them.
The purpose of WHS is not ONLY to be file server. That's one purpose, and as long as you don't edit the file on the server, you're ok.
Another purpose is to create automated remote backup of all computers on the network, basically in such a way that you can create a new image via a restore CD, but also in a way that doesn't duplicate files between images. You can also access individual files in the backup. It's like a hybrid image/file backup with duplicate file consolidation. It's pretty efficient.
Another purpose is a remote access gateway to allow you to log in via terminal services to any computer in your network.
Another purpose is to provide a web based remote access to your files.
WHS is a very useful product, and this is an unfortunate bug, but it doesn't mitigate its entire existence.
I didn't say Microsoft invented IPv6, I said they've spent significant research resources on it. They were some of the first people to implement IPv6 and provide an open source license for it. Microsoft Research fellows helped with the standardization process. See http://research.microsoft.com/msripv6/
Don't confuse Multi-Processing with Parallel Processing. They have commonality, and technically SMP is part of PP, but it's only a subset. You need to read http://en.wikipedia.org/wiki/Parallel_computing and pay close attention to the article on Automatic Parallelization. It's true that Parallel computing has been around for decades, but software still has not matured to support it. Much research is being done by many organizations on this, so don't flippantly dismiss it. And yes, it is new and inventive.
Actually, a lot of MS Research ends up in MS products. For example, the IPv6 stack in Vista was originally a MS Research project. Vista's voice recognition system is another.
The problem with all fields of research (as opposed to Development) is that most often, the results are published in journals and papers years before the technology makes it into a product, then when it finally becomes "productized" everyone yawns because "that's so old", when in reality in terms of finished products it's not.
As a good example, Microsoft is spending a ton of research on parallel processing. There are even some benefits leaking out into the real world like the Parellel Extensions to.NET.
Another good example was Microsoft Photosynth, also a Microsoft Research project that became a real-world technology.
Frankly, if you can't see any innovation coming from Microsoft, you're simply either biased, falling for the propoganda, or just not looking.
That's why I said you would be "liable". No, you're not automatically going to have problems, and you're right that the author could well issue you a new license. However, there are a lot of authors out that have used the GPL in the past and have been trying to find ways reverse that. Many authors have removed their original versions from the GPL, leaving forks still out there. Those people could, if they wanted to, use such an opportunity to reclaim all the GPL code out there, and make some money in the process.
Yes, this is all a lot of "what if", but that's precisely what a license is there to avoid. If you wanted to leave the fate of your products up to "good will" then you wouldn't need a license at all. Everyone would simply use others code while trusting they would never get sued.
And yes, it's possible you could argue various copyright defenses, but there's no guarantee they would hold up. This hasn't been tested either.
My point is simply that until the GPL is truly tested in the US, there's a risk involved with the GPL that doesn't exist with less restrictive licenses like the BSDL or Apache. How much of a risk that is, that's hard to determine. Probably not much of one, especially for non-commercial uses, but do you want to bet your business on it? I wouldn't. I won't use GPL'd code in any commercial product.
You kind of miss the point I was trying not make. I was not arguing that a court case could allow unrestricted distribution of GPL derived works. I'm more arguing that, should the GPL be found invalid, Millions of people will suddenly be violating copyright law, and that's a pretty substantial consequence to put on the shoulders of an untested license.
Let's say you create a product, such as a router. You comply with the terms of the GPL, and you produce 10,000 of these devices. Then, one day, the GPL is invalidated, and suddenly you're liable for every one of those routers you shipped. Not only that, but your customers could turn around and sue you as well.
I agree that it's pretty unlikely that could happen, but then again it's the principle of the thing that makes the GPL what it is, right?
Counting vulnerabilities is a stupid way to measure security.
So why is it, then, that for so many years those against Microsoft and Windows used every vulnerability as a chance to proclaim how much Windows sucks? Isn't that counting vulnerabilities as well?
Umm.. no. The GPL has not been tested in court. At least, not in the way you are implying. It's true that there have been a number of lawsuits against violators of the GPL, but every one of these has resulted in a settlement out of court. There has never been any decision by a court that explicitly upholds the GPL.
There is a lot of weight to the argument that a large number of settlements effectively make it "tested", but that's only really a probability, not a fact. Until such time as a decision is handed down by a court, upholding the validity of the GPL, and assigning damages to the copyright holder (either monetary or injunctive), there will still be a question.
The reason for not documenting.doc and moving documents to XML was so that these old documents would better interoperate with document management systems that understand XML, but don't understand binary formats.
There is a reason document formats are moving to XML, and it's not because of some vague concept of "perpetual" documents. Binary formats, like you mention, could just as easily be fully documented. However, binary documents are not the direction that document management and archiving systems are moving. It makes more sense to document old formats by converting them to an XML representation, thus killing two birds with one stone.
It's there for documents converted from the really old legacy documents. There are only a couple of tags that are even related to old Office, most of them are there for documents originally converted from Lotus or Wordperfect.
jpeg doesn't contain the specification for gif because jpeg is not intended as a way to losslessly represent gif files in a standardized format. OOXML *IS* intended to losslessly represent legacy documents (as well as current documents) in a standardized format.
ODF is a new format that has very little legacy concerns, OOXML is concerned with legacy because there are hundreds of federal regulations that require documents to be preserved as originally written, which means the data in the document cannot change, though the format that data is represented with can.
Why are there references to K&R function signatures in ISO C89? The answer should be obvious to anyone that's even marginally objective on the subject. Legacy has to be documented, even if it's no longer officially supported.
Office 2007 will not create new documents with those tags. Documents converted as far back as Word 2000 or Excel 2000 won't contain any of those tags. Only documents converted originally from WordPerfect and Office 95 could contain them (I don't recall, there might be an Office 97 tag in there as well, but I don't think so).
The only documents that might contain those tags are older than 10 years old that have been converted to OOXML. And it's largely safe to ignore those tags even if they're there, since they don't map to any critical functionality. If the tag is there for WordPefect line spacing, just use normal line spacing, chances are the document will look fine, but you might want to flag a conversion error anyways saying "deprecated element found, check document for accuracy".
Do you not really see how much of a hypocrite you're being?
Let me spell it out for you.
Argument 1:
OOXML isn't an ISO standard, there already exists one called ODF. Microsoft should use that, because it's an ISO standard.
Argument 2:
Miguel sucks for supporting mono because it comes from Microsoft. (Strange, no comment on the fact that Mono is an implementation of an ISO standard, while Java is not).
Why is it that ODF rules because it's an ISO standard, but Java rules despite not being one, and the real ISO standard is bashed?
A small correction. OOXML is *capable* of specifying the behavior 99.99% of the worlds actual Office documents. Most of those documents are in.doc and xls format, not.docx and xlsx. I say that because you'll likely get beat up over that little detail, which is for the most part irrelevant.
Why is it irrelevant? Because OOXML is basically just a different way of expressing the binary format of Office, thus conversion from.doc or.xls to OOXML merely involves changing the structure of the data, not the interpretation of it. ODF, on the other hand, requires that documents that are converted from.doc or.xls be *TRANSLATED* as well as converted. This is a big issue, because as we all know from google translate or babelfish, translations are seldom 100% accurate.
Microsoft claims that ODF isn't capable of expressing 100% of OOXML's data. I don't know if that's true. It may be possible to do a rough translation of most of it, but there will always be a certain amount of something that gets lost in the translation. ODF is likely capable of representing 90+% of the documents accurately (even with translation) but it's that 10% that will be painful.
No, OOXML isn't an "elegant" or even "pretty" format. It's full of hacks and nastiness that only comes from decades of cruft. But the fact remains that there are billions of documents out there in legacy formats, and those documents need to (eventually) get moved to something that's fully documented and easy to utilize. It makes a lot more sense to move them to an XML'd version of the legacy binary documents than it does to move them to ODF.
If we were dropping support for legacy documents, then i'd say go with ODF 100%. Most of the people in the ODF camp don't seem to understand the importance of legacy support, or they're actively trying to distract you from considering it.
Since when are deprecated flags that are actively considered illegal to even use in any new document considered a "critical part"?
Here's a suggestion. Why don't you actually READ the specification related to those items. They're not big.
Let's use C++ as an example. ISO standard C89 mentions that old style K&R function definitions are around in pre-standard code, however that style of code is deprecated. Most compilers still accept K&R style unless you tell the compiler to only accept standard, non-deprecated code. However, there is nothing critical about such functionality and a compiler that doesn't conform to K&R is perfectly legal.
This is basically the same thing. There are elements that can appear in legacy documents that have been converted to the new format that are deprecated. You don't have to support them to conform to the standard, because the standard makes them officially unsupported.
The Non-XML formatting codes are not invalid XML, they're simply custom defined XML. They're still valid markup. The Bitmasks are also valid, just not easy to use in many implementations.
XML doesn't define a date format, as such any date format is valid. It can't be "not in the spirit of XML" because XML doesn't have a spirit when it comes to dates. You're applying different arguments to the wrong subject. But that's typical of someone that merely repeats what he's told, and doesn't actually understand what it is he's arguing about.
Your arguments are patently ridiculous. Something cannot be "invalid XML" "in spirt". That's just wishful thinking on your part. None of your arguments bring up any technical invalidity. All "valid XML" means is that the code can be parsed by a valid XML implementation. OOXML is certainly that.
What's more, the term "in the spirit" means "In the manner for which it was designed". The problem with your argument is that none of the things you mention existed when XML was designed, so it's impossible for "violations" of those things to not be "in the spirit".
Basically, your argument is that you don't like the design choices MS made. That's a fair argument, but you seem to feel the need to embellish your argument by making false claims of invalidity, then trying to use a fallacious "in the spirit" argument to back it up.
I can't argue about Finish versions of Word, as I have no basis to discuss that. However, your arguments about ancient versions of word, while you have a point, are not particularly relevant because the vast majority of documents out there will not be from versions quite that old (though there may be some) and such documents would almost certainly fail in the conversion process, allowing them to be analyzed manually. There are reasons beyond mere faithfulness of data that result in what you've seen, most likely the largest one being that the fonts used in the document don't exist on the machine it where it was converted. This is a problem with ODF as well as OOXML, but has nothing to do with the conversion of the document. If you had a copy of Word 2.0 to open that document, you'd have the same problem.
And, BTW, you might want to update your arguments. OOXML doesn't use bitmaps in the XML, it stores them as binary files in zip archives, just like OpenOffice does. While I believe the format doesn't disallow it, as this was used in Office 2003 XML formats, it was changed for OOXML. But you see, that's the problem with the majority of the arguments against OOXML made by people that really don't know anything about OOXML, they only parrot what they've been told (by people with financial interests in seeing OOXML fail)... thus they don't really know if the arguments they are so vigorously making are, in fact, true or not.
There's no doubt that OOXML has plenty of problems, and I would hazard a guess that if Microsoft were to design a new format without considering backwards compatibility, it would be vastly different. But reality is that backwards compatibility is the #1 issue facing any document format, and that's why ODF will ultimately fail. Those organizations that are being snowballed into mandating ODF will soon discover the problems inherent in translative conversion, and when they start violating other laws regarding document archiving fidelity, they'll be in a bit of a paradox.
Excuse me? OOXML is, in fact, fully valid XML. Where do you get that idea from?
I didn't say there were billions of documents using OOXML. Yes, there are billions of legacy.doc and xls and ppt files. And there is, in fact, a known converter. Dozens of them in fact. Office itself is one giant converter that can be controlled via script. Office 2007 can read a binary document, save it as OOXML and none of the data changes because all the same binary elements are represented by xml elements. Conversion of such documents are completely feasible because the document conversion can occur automatically, without the need to verify if the the document still looks the same, or if any data got lost.
The same is not true of conversion to ODF, or any other format that isn't 1:1 compatible with the binary formats.
Sun and IBM are not going to amend ODF to suit MS Office. In fact, they worked very hard to exclude anything that could make ODF compatible with Office, according to Marbux and Gary Edwards. They claimed that Sun and IBM explicitly shot down anything that could make ODF interoperable with Office. It's not in Sun's or IBM's best interest to allow Microsoft to compete fairly, which is why they spend so much time FUDing OOXML rather than promoting ODF.
I'm not sure it makes any more sense to make the binary format an ISO standard than it does to make OOXML one. OOXML is basically just the binary documents expressed in XML. It's more interoperable than a binary format because it allows documents to be used more easily in text processing systems, and online document management systems. Thus, the billions of legacy documents can be converted to a format that is more interoperable, without the need to verify whether the conversion was accurate or not.
Sure, a large percentage of documents *COULD* be converted to ODF, but because the formats are not 1:1, it would require each document to be analyzed after conversion to determine if the translation was accurate or not. OOXML is 1:1 with the binary format, meaning it's just a different way of expressing the same data. ODF requires "translation", not just conversion. This is the need that OOXML fills, bringing legacy binary documents into the age of interoperable XML.
Even if MS made Office save all new documents as ODF, and reserved OOXML only for conversion of legacy documents, i'd still say OOXML needs to be standardized, simply for the fact that there are billions of documents that would benefit from it.
The fact of the matter is, either the binary formats or OOXML have to be standardized, because governments want their legacy documents in a standard format, and conversion to ODF just isn't feasible. It would be like trusting the conversion of billions of important documents from english to japanese to Google Translator, without anyone manually verifying the translation of each and every document.
As for your last point, about Microsoft using a different format, that's no different than OpenOffice who are working on new versions of ODF as well, so that's not a very practical argument. All standard formats have errata and require maintenance to fix problems. Neither OOXML or ODF are immune to that.
Slashdot Mirror
Where, precisely, did he say he was using Linux as the client? He didn't, he said Linux as the backup server. And BackupPC seem sto be more oriented towards Windows backups since it uses SMB rather than NFS for it's backups.
Nice rant, but you seem to be ranting about something that wasn't even implied in the original message.
BackupPC does many of those functions, but you can't restore the entire computer from a blank disk.
Actually, it's a little bit more than that. For example, you can completely restore a PC, like if you had use Ghost, but at the same time it gives you full access to the files as if you used a file backup. What's more, it consolidates duplicate files in the backups so that they don't take up extra space.
You can also add storage to the thing just by dropping in a new disk and telling it to use it. No re-partitioning, or mounting partitions in subfolders. it spans drives and provides automatic redundancy without RAID and the associated probles with adding new storge to RAID volumes.
It also has a neat "plug-in" feature that allows third parties to extend it. Here's some examples:
http://www.microsoft.com/windows/products/winfamily/windowshomeserver/partners/challenge.mspx
I'll grant you that today, it's still in the "it has lots of potential" phase.
Not exactly. You're confusing file sharing with backups. The problem occurs when you edit a file that is stored on the Windows Server file shares, the backup of the file on the file share may become corrupt. However, files backed up via the backup agent from your local computer are not corrupted when you edit them.
Your question is based on a flawed predicate.
The purpose of WHS is not ONLY to be file server. That's one purpose, and as long as you don't edit the file on the server, you're ok.
Another purpose is to create automated remote backup of all computers on the network, basically in such a way that you can create a new image via a restore CD, but also in a way that doesn't duplicate files between images. You can also access individual files in the backup. It's like a hybrid image/file backup with duplicate file consolidation. It's pretty efficient.
Another purpose is a remote access gateway to allow you to log in via terminal services to any computer in your network.
Another purpose is to provide a web based remote access to your files.
WHS is a very useful product, and this is an unfortunate bug, but it doesn't mitigate its entire existence.
If you open My Computer and type a URL in the address bar it will become Internet Explorer and that is the problem...
Except that doesn't happen anymore. Vista removed the integration between the shell and IE.
I didn't say Microsoft invented IPv6, I said they've spent significant research resources on it. They were some of the first people to implement IPv6 and provide an open source license for it. Microsoft Research fellows helped with the standardization process. See http://research.microsoft.com/msripv6/
Don't confuse Multi-Processing with Parallel Processing. They have commonality, and technically SMP is part of PP, but it's only a subset. You need to read http://en.wikipedia.org/wiki/Parallel_computing and pay close attention to the article on Automatic Parallelization. It's true that Parallel computing has been around for decades, but software still has not matured to support it. Much research is being done by many organizations on this, so don't flippantly dismiss it. And yes, it is new and inventive.
If you want to see Microsoft Research contributions to real products, check this page http://research.microsoft.com/aboutmsr/pastpresentfuture/contributions.aspx
Actually, a lot of MS Research ends up in MS products. For example, the IPv6 stack in Vista was originally a MS Research project. Vista's voice recognition system is another.
.NET.
The problem with all fields of research (as opposed to Development) is that most often, the results are published in journals and papers years before the technology makes it into a product, then when it finally becomes "productized" everyone yawns because "that's so old", when in reality in terms of finished products it's not.
As a good example, Microsoft is spending a ton of research on parallel processing. There are even some benefits leaking out into the real world like the Parellel Extensions to
Another good example was Microsoft Photosynth, also a Microsoft Research project that became a real-world technology.
Frankly, if you can't see any innovation coming from Microsoft, you're simply either biased, falling for the propoganda, or just not looking.
That's why I said you would be "liable". No, you're not automatically going to have problems, and you're right that the author could well issue you a new license. However, there are a lot of authors out that have used the GPL in the past and have been trying to find ways reverse that. Many authors have removed their original versions from the GPL, leaving forks still out there. Those people could, if they wanted to, use such an opportunity to reclaim all the GPL code out there, and make some money in the process.
Yes, this is all a lot of "what if", but that's precisely what a license is there to avoid. If you wanted to leave the fate of your products up to "good will" then you wouldn't need a license at all. Everyone would simply use others code while trusting they would never get sued.
And yes, it's possible you could argue various copyright defenses, but there's no guarantee they would hold up. This hasn't been tested either.
My point is simply that until the GPL is truly tested in the US, there's a risk involved with the GPL that doesn't exist with less restrictive licenses like the BSDL or Apache. How much of a risk that is, that's hard to determine. Probably not much of one, especially for non-commercial uses, but do you want to bet your business on it? I wouldn't. I won't use GPL'd code in any commercial product.
Umm. no. I'm talking about:
Headline: Microsoft releases 3 patches on patch tuesday
Reaction: ZOMG!!! This just goes to show how much Windows sucks!!! Use Linux or Firefox or Thunderbird or MacOS!!!!
What does VML have to do with the undocumented tags mentioned? VML is fully documented, though it's not an ISO standard.
You kind of miss the point I was trying not make. I was not arguing that a court case could allow unrestricted distribution of GPL derived works. I'm more arguing that, should the GPL be found invalid, Millions of people will suddenly be violating copyright law, and that's a pretty substantial consequence to put on the shoulders of an untested license.
Let's say you create a product, such as a router. You comply with the terms of the GPL, and you produce 10,000 of these devices. Then, one day, the GPL is invalidated, and suddenly you're liable for every one of those routers you shipped. Not only that, but your customers could turn around and sue you as well.
I agree that it's pretty unlikely that could happen, but then again it's the principle of the thing that makes the GPL what it is, right?
Counting vulnerabilities is a stupid way to measure security.
So why is it, then, that for so many years those against Microsoft and Windows used every vulnerability as a chance to proclaim how much Windows sucks? Isn't that counting vulnerabilities as well?
Umm.. no. The GPL has not been tested in court. At least, not in the way you are implying. It's true that there have been a number of lawsuits against violators of the GPL, but every one of these has resulted in a settlement out of court. There has never been any decision by a court that explicitly upholds the GPL.
There is a lot of weight to the argument that a large number of settlements effectively make it "tested", but that's only really a probability, not a fact. Until such time as a decision is handed down by a court, upholding the validity of the GPL, and assigning damages to the copyright holder (either monetary or injunctive), there will still be a question.
The reason for not documenting .doc and moving documents to XML was so that these old documents would better interoperate with document management systems that understand XML, but don't understand binary formats.
There is a reason document formats are moving to XML, and it's not because of some vague concept of "perpetual" documents. Binary formats, like you mention, could just as easily be fully documented. However, binary documents are not the direction that document management and archiving systems are moving. It makes more sense to document old formats by converting them to an XML representation, thus killing two birds with one stone.
It's there for documents converted from the really old legacy documents. There are only a couple of tags that are even related to old Office, most of them are there for documents originally converted from Lotus or Wordperfect.
jpeg doesn't contain the specification for gif because jpeg is not intended as a way to losslessly represent gif files in a standardized format. OOXML *IS* intended to losslessly represent legacy documents (as well as current documents) in a standardized format.
ODF is a new format that has very little legacy concerns, OOXML is concerned with legacy because there are hundreds of federal regulations that require documents to be preserved as originally written, which means the data in the document cannot change, though the format that data is represented with can.
Why are there references to K&R function signatures in ISO C89? The answer should be obvious to anyone that's even marginally objective on the subject. Legacy has to be documented, even if it's no longer officially supported.
"apparently"? What makes you think that?
Office 2007 will not create new documents with those tags. Documents converted as far back as Word 2000 or Excel 2000 won't contain any of those tags. Only documents converted originally from WordPerfect and Office 95 could contain them (I don't recall, there might be an Office 97 tag in there as well, but I don't think so).
The only documents that might contain those tags are older than 10 years old that have been converted to OOXML. And it's largely safe to ignore those tags even if they're there, since they don't map to any critical functionality. If the tag is there for WordPefect line spacing, just use normal line spacing, chances are the document will look fine, but you might want to flag a conversion error anyways saying "deprecated element found, check document for accuracy".
Do you not really see how much of a hypocrite you're being?
Let me spell it out for you.
Argument 1:
OOXML isn't an ISO standard, there already exists one called ODF. Microsoft should use that, because it's an ISO standard.
Argument 2:
Miguel sucks for supporting mono because it comes from Microsoft. (Strange, no comment on the fact that Mono is an implementation of an ISO standard, while Java is not).
Why is it that ODF rules because it's an ISO standard, but Java rules despite not being one, and the real ISO standard is bashed?
A small correction. OOXML is *capable* of specifying the behavior 99.99% of the worlds actual Office documents. Most of those documents are in .doc and xls format, not .docx and xlsx. I say that because you'll likely get beat up over that little detail, which is for the most part irrelevant.
.doc or .xls to OOXML merely involves changing the structure of the data, not the interpretation of it. ODF, on the other hand, requires that documents that are converted from .doc or .xls be *TRANSLATED* as well as converted. This is a big issue, because as we all know from google translate or babelfish, translations are seldom 100% accurate.
Why is it irrelevant? Because OOXML is basically just a different way of expressing the binary format of Office, thus conversion from
Microsoft claims that ODF isn't capable of expressing 100% of OOXML's data. I don't know if that's true. It may be possible to do a rough translation of most of it, but there will always be a certain amount of something that gets lost in the translation. ODF is likely capable of representing 90+% of the documents accurately (even with translation) but it's that 10% that will be painful.
No, OOXML isn't an "elegant" or even "pretty" format. It's full of hacks and nastiness that only comes from decades of cruft. But the fact remains that there are billions of documents out there in legacy formats, and those documents need to (eventually) get moved to something that's fully documented and easy to utilize. It makes a lot more sense to move them to an XML'd version of the legacy binary documents than it does to move them to ODF.
If we were dropping support for legacy documents, then i'd say go with ODF 100%. Most of the people in the ODF camp don't seem to understand the importance of legacy support, or they're actively trying to distract you from considering it.
Since when are deprecated flags that are actively considered illegal to even use in any new document considered a "critical part"?
Here's a suggestion. Why don't you actually READ the specification related to those items. They're not big.
Let's use C++ as an example. ISO standard C89 mentions that old style K&R function definitions are around in pre-standard code, however that style of code is deprecated. Most compilers still accept K&R style unless you tell the compiler to only accept standard, non-deprecated code. However, there is nothing critical about such functionality and a compiler that doesn't conform to K&R is perfectly legal.
This is basically the same thing. There are elements that can appear in legacy documents that have been converted to the new format that are deprecated. You don't have to support them to conform to the standard, because the standard makes them officially unsupported.
The Non-XML formatting codes are not invalid XML, they're simply custom defined XML. They're still valid markup.
The Bitmasks are also valid, just not easy to use in many implementations.
XML doesn't define a date format, as such any date format is valid. It can't be "not in the spirit of XML" because XML doesn't have a spirit when it comes to dates. You're applying different arguments to the wrong subject. But that's typical of someone that merely repeats what he's told, and doesn't actually understand what it is he's arguing about.
Your arguments are patently ridiculous. Something cannot be "invalid XML" "in spirt". That's just wishful thinking on your part. None of your arguments bring up any technical invalidity. All "valid XML" means is that the code can be parsed by a valid XML implementation. OOXML is certainly that.
What's more, the term "in the spirit" means "In the manner for which it was designed". The problem with your argument is that none of the things you mention existed when XML was designed, so it's impossible for "violations" of those things to not be "in the spirit".
Basically, your argument is that you don't like the design choices MS made. That's a fair argument, but you seem to feel the need to embellish your argument by making false claims of invalidity, then trying to use a fallacious "in the spirit" argument to back it up.
I can't argue about Finish versions of Word, as I have no basis to discuss that. However, your arguments about ancient versions of word, while you have a point, are not particularly relevant because the vast majority of documents out there will not be from versions quite that old (though there may be some) and such documents would almost certainly fail in the conversion process, allowing them to be analyzed manually. There are reasons beyond mere faithfulness of data that result in what you've seen, most likely the largest one being that the fonts used in the document don't exist on the machine it where it was converted. This is a problem with ODF as well as OOXML, but has nothing to do with the conversion of the document. If you had a copy of Word 2.0 to open that document, you'd have the same problem.
And, BTW, you might want to update your arguments. OOXML doesn't use bitmaps in the XML, it stores them as binary files in zip archives, just like OpenOffice does. While I believe the format doesn't disallow it, as this was used in Office 2003 XML formats, it was changed for OOXML. But you see, that's the problem with the majority of the arguments against OOXML made by people that really don't know anything about OOXML, they only parrot what they've been told (by people with financial interests in seeing OOXML fail)... thus they don't really know if the arguments they are so vigorously making are, in fact, true or not.
There's no doubt that OOXML has plenty of problems, and I would hazard a guess that if Microsoft were to design a new format without considering backwards compatibility, it would be vastly different. But reality is that backwards compatibility is the #1 issue facing any document format, and that's why ODF will ultimately fail. Those organizations that are being snowballed into mandating ODF will soon discover the problems inherent in translative conversion, and when they start violating other laws regarding document archiving fidelity, they'll be in a bit of a paradox.
Excuse me? OOXML is, in fact, fully valid XML. Where do you get that idea from?
.doc and xls and ppt files. And there is, in fact, a known converter. Dozens of them in fact. Office itself is one giant converter that can be controlled via script. Office 2007 can read a binary document, save it as OOXML and none of the data changes because all the same binary elements are represented by xml elements. Conversion of such documents are completely feasible because the document conversion can occur automatically, without the need to verify if the the document still looks the same, or if any data got lost.
I didn't say there were billions of documents using OOXML. Yes, there are billions of legacy
The same is not true of conversion to ODF, or any other format that isn't 1:1 compatible with the binary formats.
Sun and IBM are not going to amend ODF to suit MS Office. In fact, they worked very hard to exclude anything that could make ODF compatible with Office, according to Marbux and Gary Edwards. They claimed that Sun and IBM explicitly shot down anything that could make ODF interoperable with Office. It's not in Sun's or IBM's best interest to allow Microsoft to compete fairly, which is why they spend so much time FUDing OOXML rather than promoting ODF.
Yes, point #1 is the reason.
I'm not sure it makes any more sense to make the binary format an ISO standard than it does to make OOXML one. OOXML is basically just the binary documents expressed in XML. It's more interoperable than a binary format because it allows documents to be used more easily in text processing systems, and online document management systems. Thus, the billions of legacy documents can be converted to a format that is more interoperable, without the need to verify whether the conversion was accurate or not.
Sure, a large percentage of documents *COULD* be converted to ODF, but because the formats are not 1:1, it would require each document to be analyzed after conversion to determine if the translation was accurate or not. OOXML is 1:1 with the binary format, meaning it's just a different way of expressing the same data. ODF requires "translation", not just conversion. This is the need that OOXML fills, bringing legacy binary documents into the age of interoperable XML.
Even if MS made Office save all new documents as ODF, and reserved OOXML only for conversion of legacy documents, i'd still say OOXML needs to be standardized, simply for the fact that there are billions of documents that would benefit from it.
The fact of the matter is, either the binary formats or OOXML have to be standardized, because governments want their legacy documents in a standard format, and conversion to ODF just isn't feasible. It would be like trusting the conversion of billions of important documents from english to japanese to Google Translator, without anyone manually verifying the translation of each and every document.
As for your last point, about Microsoft using a different format, that's no different than OpenOffice who are working on new versions of ODF as well, so that's not a very practical argument. All standard formats have errata and require maintenance to fix problems. Neither OOXML or ODF are immune to that.