1. Apparently no one but you was able to reproduce suspend/resume problem, and after your laptop was broken there was nothing to test. What the Hell did you expect? Very likely the problem is tied to specific BIOS, ACPI configuration or hardware release version, what you never bothered to test. Also no attempts to check how behavior changes if you force unloading driver before suspend/reloading after resume.
2. I have no idea why X11 is brought up in discussion -- by your description it looks like the problem does not happen in X.
Plenty of graphics adapters are unsupported by native framebuffer drivers, so everyone uses vesa or text mode for those. No modern general-purpose Linux program uses framebuffer for graphics directly, so unless your adapter is unsupported by X drivers, all you have lost is boot splash. Boo-hoo.
It's to the point that there are only 3 types of Linux progs that work: the one that comes with the system (and its updates), the simple "./configure; make; make install" and the kind I write myself.
What is this mysterious other kind of application that exists for Linux? I am using it since 1994, and have yet to find the other kind.
Unless you mean, commercial binary packages, that I have never seen failing unless I intentionally mess with them far beyond their intended flexibility, what would break them on any OS.
1. Distributions are binary-incompatible across DISTRIBUTION-PROVIDED software. Third-party software usually runs on everything, ex: binaries of Firefox, Adobe Reader, Flash, etc.
2. All distributions have their build procedure published. Supporting a distribution is a matter of following simple build directions.
Of course, being completely unaware of anything even remotely related to development for Linux, you didn't know that, and therefore were repeating the words of your friendly Microsoft marketing person.
it's things like slightly shifted terminal console,
Only happens on NON-LAPTOP computers with analog LCD monitors (solution: press "Auto-Adjust" and "Save" on your monitor while console text is displayed).
no sound after resuming from hibernation
Only happens on LAPTOP computers (who hibernates a desktop?, solution: update BIOS to a non-broken version).
Now, please, tell me, how did you encounter both "problems" at the same time, and if they aren't in fact the result of a google search for "linux problem"?
What the Hell are you talking about? Jeremy Allison "endorsed" some modern amateurish criticism (and my whole point is that such an "endorsement" is stupid, be it by Jeremy Allison or anyone else).
I am referring to the Unix Haters Handbook, similar text that was published 14 years ago and since then shown itself to be completely worthless for any purpose other than promoting the use of Windows to ignorant people.
First we had Ubentu Hardy Herring installed it for the most part worked however the Wireless card wouldn't work with WPA2 connection (other connection worked fine) So I had to downgrade to 7.10 and Wireless worked.
So you have downgraded to an obsolete version just because Network Manager or your card's driver for some reason did not automatically recognize your WPA2 network? Instead of, umm, replacing either of those components with one that works? And you claim that you used various OS, including Linux, before. Just how stupid are you?
I am typing this on a laptop with Ralink wireless card. Running Ubuntu Hardy. Network Manager does not work with it, either -- RutilT does, and that was the only thing I had to add.
...usually because they tried to compete with a free Linux application. The application may be useful, but many potential users don't see a benefit because they already have something that suits their needs, so the only people who buy it are ones who need precisely this application.
Extreme example: whose bright idea was to make Nero for Linux when K3B is far, far superior?
Unrelated to this, I doubt that many companies actually count sales by platforms -- licenses are usually portable between platforms, so purchaser for the company may ask for a license file checking "Windows" then the actual user installs a Linux binary. Recently I had to download one very expensive package for Windows just to get a Java-dependent installer to run (Linux packaging was hopelessly broken), then run the actual package (that included Linux binaries) exclusively on Linux. All, of course, complying with the license that was for one copy on either platform.
I can only add to it that "Unix Haters Handbook", ancient as it is, contained absolutely no information that was in any way useful for improving Unix or Unix-like systems -- the supposed flaws were either nonexistent, or became irrelevant after natural progress of technology.
It's especially easy to see on example of X11. OSX went into NeXT-like direction of replacing X, Windows as usual continued pushing DirectX and made yet another two layers above and below everything, Linux developers continued with Xorg/freedesktop.org direction. Current status: X kept all its advantages even after adding all infrastructure for widgets and high-level UI support, and all the eye candy from OpenGL and Composite, Windows Vista UI improvements seem to be mostly successful at wasting resources and irritating users, OSX added clumsy (tvwm-like at best) multiple desktops in latest version, and has no remote capabilities beyond VNC.
Apparently "over-engineered" X11 design was the right thing to do all along -- only Xaw and Motif really had to be abandoned, but that was not something that cheerful "Unix hater" would tell you from his comfy office on Redmond.
So no, this "criticism" is a worthless waste of time. Real users see real problems, ideology warriors write holy books decrying their enemies supposed deficiencies.
Blizzard can claim that they wouldn't sell you the copy if you didn't agree to EULA, however this is a pretty idiotic reasoning considering that you are not presented with EULA at the time of purchase.
The only thing Blizzard can do is to deny their service to those who don't agree to EULA, or break it after accepting -- after all, service contract is all that matters here, game is useless without the service. The problem is, Blizzard has no technical capability to do so (they can't stand behind each user's back, so they would be able to determine if he does or doesn't violate their license), and therefore makes ridiculous claims about scope of their rights.
GPL can't prevent you from using the program in whatever way you wish to use it or modify it. It can only deprive you from the right to distribute it or anything based on it (what copyright actually covers, and GPL grants to the recipient).
You might have not noticed, but it's not just XML. Almost everyone has moved to Unicode now, and those who haven't yet (Ruby, PHP) are being mocked for just that, and have the move on the top of their TODO. Learn to live with it already.
Actually no. I know because I am Russian.
You are extremely confused here. Neither of these: "capitalization procedure, spellchecker, hyphenation, phonetic match, acronym expansion, index sorting" - has anything to do with charset or encoding; none whatsoever. This is because encoding has nothing to do with a language. UTF-8 is an encoding which can handle hundreds of languages. Latin-1 is another one that can handle perhaps several dozen. Windows-1251, IIRC, can handle both Russian and Belarusian. It really does not matter. What matters is the language of the text and the associated culture (aka "locale") - trying to infer it from encoding or charset is silly and, in the end, futile.
"Locale" is NEVER about handling of data, only about presentation of it to the user and locally defined elements of user interface. Language in a document has to be always handled in exactly the same way as long as it's the same language, regardless of what user's settings are. There may not even be a "user" or "locale" for non-interactive data processing. People suffered more than enough with "locale" settings in databases mangling their data already.
And, surprise surprise, XML has a standard mechanism to associate content of an element with a specific language - it's xml:lang attribute. So, whenever you write, for example, an XHTML document that contains both English and Russian, all you need is to surround parts of texts in another language with span or div, and mark them with xml:lang. It's even specifically mentioned in the XHTML spec.
Apparently you haven't read what I wrote.
XML "allows" to handle languages. The problem is, it does not force implementors to handle them because it allows an easy shortcut. And implementors who knew nothing about language metadata that may be relevant (pretty much all of people who pushed for Unicode in the first place) didn't feel an obligation to support any kind of language-dependent processing. If the standard forced them to handle multiple charsets, they would not be able to create this fake language support -- at the moment the application encountered anything beyond their beloved ISO-8859-1 (what would be 99% of "Unicode" documents those people seen), it would have to perform some metadata-dependent text handling -- for both charset and language. Application would have two choices -- never assume anything about a language and pass data transparently, or call charset/language-dependent handling for everything they do that may be dependent on charset and language. Since this wasn't done, at this point not a single piece of software actually supports multiple languages in a way that XML and Unicode-promoters promised. Not OpenOffice.org, not Microsoft Office, not text input in any UI toolkit, not mailreaders, not databases. Every time someone implements a particular language support or common support for multiple languages, it has to be done in a way that breaks the intended model of metadata handling in XML, and imposes "special" rules on Unicode ranges that have nothing to do with Unicode standard.
You may claim that those are all crappy implementations, however my point is, the standard was specifically designed to allow developers hide behind pretty pictures that look like text is "foreign" languages -- except really there is no language support whatsoever.
You might have not noticed, but it's not just XML. Almost everyone has moved to Unicode now, and those who haven't yet (Ruby, PHP) are being mocked for just that, and have the move on the top of their TODO. Learn to live with it already.
Actually no. I know because I am Russian.
You are extremely confused here. Neither of these: "capitalization procedure, spellchecker, hyphenation, phonetic match, acronym expansion, index sorting" - has anything to do with charset or encoding; none whatsoever. This is because encoding has nothing to do with a language. UTF-8 is an encoding which can handle hundreds of languages. Latin-1 is another one that can handle perhaps several dozen. Windows-1251, IIRC, can handle both Russian and Belarusian. It really does not matter. What matters is the language of the text and the associated culture (aka "locale") - trying to infer it from encoding or charset is silly and, in the end, futile.
And, surprise surprise, XML has a standard mechanism to associate content of an element with a specific language - it's xml:lang attribute. So, whenever you write, for example, an XHTML document that contains both English and Russian, all you need is to surround parts of texts in another language with or
, and mark them with xml:lang. It's even specifically mentioned in the XHTML spec.
Apparently you haven't read what I wrote.
XML "allows" to handle languages. The problem is, it does not force implementors to handle them because it allows an easy shortcut. And implementors who knew nothing about language metadata that may be relevant (pretty much all of people who pushed for Unicode in the first place) didn't feel an obligation to support any kind of language-dependent processing. If the standard forced them to handle multiple charsets, they would not be able to create this fake language support -- at the moment the application encountered anything beyond their beloved ISO-8859-1 (what would be 99% of "Unicode" documents those people seen), it would have to perform some metadata-dependent text handling -- for both charset and language. Application would have two choices -- never assume anything about a language and pass data transparently, or call charset/language-dependent handling for everything they do that may be dependent on charset and language. Since this wasn't done, at this point not a single piece of software actually supports multiple languages in a way that XML and Unicode-promoters promised. Not OpenOffice.org, not Microsoft Office, not text input in any UI toolkit, not mailreaders, not databases. Every time someone implements a particular language support or common support for multiple languages, it has to be done in a way that breaks the intended model of metadata handling in XML, and imposes "special" rules on Unicode ranges that have nothing to do with Unicode standard.
You may claim that those are all crappy implementations, however my point is, the standard was specifically designed to allow developers hide behind pretty pictures that look like text is "foreign" languages -- except really there is no language support whatsoever.
I should have been clearer and said 'non-database'... But yes you are correct a formal relational database is great way to store static information it can automatically enforce it's schema and basic semantic integrity. Anyone who uses XML as a replacement for a database is using to much of it. Like I've stressed before XML is a poor format for static data storage. If the data isn't going to be transformed, aggregated, filtered, or translated at some time in the future; then XML may not be best choice for storage. To state it differently: XML is meant to be used for transportation vs. storage of data.
Databases are tied to a single data model, and their access protocols are not designed for efficient bulk data transfer. The major justification for XML (and all its possible replacements) was support for data that is not limited to a relational data model.
Essentially what you are describing is IDL with a touch of COM.
IDL is primitive, and COM ties general semantics to particular application's implementation and does not translate beyond it without a manual reimplementation. Neither counts as a formal semantics definition.
This a big shift in program design (specifically what constitutes a 'program'). Instead of monolithic code bases you have distributed servlets and transformation processes. A 'program' can be an abstracted service or it could be the description of the processing and filtering chain combining the resources of third party data sources and services.
Commingling of data format and consistency support with implementation-specific logic is a design deficiency, not a requirement for data consistency support.
It called documentation...
Documentation is informal -- it requires a human to interpret and implement, and it almost never gives unambiguous definition for all possible behaviors that can be expected from a system. If you look at any documentation that accompanies XML-based formats, it's a huge mass of words that can mean pretty much anything, and this is the root of all incompatibility.
To make a system reliable, formats have to be defined formally, and all behavior has to be reflected in an unambiguous way. Then even if behavior is not what a programmer wants or expects, he can be sure what it actually is.
No, Oakland has a horrendous amount of crime because it has a horrendous amount of criminals. You don't live around here, do you?
Actually I do live around there. Last time I checked, criminals are not a part of indigenous flora or fauna -- they flourish wherever there are conditions conducive to crime. A combination of poverty, shitty city planning, and as we see by this example incompetent law enforcement definitely counts as "conducive to crime".
The car with the passenger's seat removed and the floor wet as if it had been washed, found on an Oakland street yet not reported stolen
I guess, It was not reported stolen because it wasn't stolen. Thousands of people leave their cars on the streets in conditions far worse and weirder than that -- should we round them up and prosecute for the nearest recent unsolved crime?
Nina's vehicle, also found on an Oakland street but not reported stolen
That would be consistent with any kind of sudden disappearance except one (if she left Oakland in her van). Nothing links it to Hans.
The fact that he was the last person known to have seen her alive
If that qualified as a proof, we would be able to just convict the last person who had seen each and every victim of unsolved murder.
His testimony, which was probably more damning than much of the other evidence. OK, I think his testimony was crap too, and from a getting away with it perspective he was an idiot to take the stand, but I don't think it was crap the way you think it was crap. You seem to have believed him. Maybe you still believe him, even though he has now confessed and her body has been found.
Actually the only thing his testimony is good for is to confirm that he is not a social person, and that he was scared when police was obviously hounding him. What was known from the very beginning. I know plenty of people who behave in a similar manner, none of them committed an offense worse than speeding. If people were imprisoned based on those things alone, there would be, among other things, a lot of software without maintainers.
Or put another way, "if it walks like a duck and quacks like a duck..."
This is precisely what the presumption of innocence, burden of proof and various other fundamental concepts in law enforcement and justice supposed to prevent. Despite the fact that often such a guess is actually correct. Police and prosecution have to provide a proof, something that excludes the possibility that there was a peculiar combination of circumstances and misdirection that merely suggests someone's guilt. And in case of this murder they had ample opportunity to do so by collecting evidence, excluding various other "colorful characters" involved, not messing up collection of blood from the house, interviewing kids in a manner appropriate for the situation, making more of an effort to find the body and, of course, not spending weeks trying to prove that Hans was not a nice person (they would get essentially the same information from LKML archive).
Instead police and prosecution relied entirely on lucky guesses and random smear campaign in front of jury composed of people unfamiliar with antisocial nerds such as Hans. That sloppy police work, strategy of investigation and prosecution that chases after low-hanging fruit and does not doubt superficial impressions, goes a long way explaining why you have to be a mathematician to be prosecuted for a serious crime in Oakland. What is also not an actual proof but merely a plausible explanation of the fact that non-nerdy criminals terrorize Oakland with impunity.
For the record, there is nothing I like more than writing custom parsers its hella fun! That being said; I have things to do other than watch Matlock and write parsers for no good reason (it's like knitting for DPD-11 crowd).
Parsers are generated by automated tools. To be precise, XML parsers are among few exceptions that are not generated.
Your argument about implementation is a red herring. If by semantics you are refering to application-level semantics then yes you have to provide an implementation. Show me a file-oriented data storage method that automatically handles application level semantics.
Any modern relational database has minimal semantics support -- it allows to define constraints, references and indexes that reflect application semantics as well as table structure that reflect syntax. Some databases (ex: Oracle, PostgreSQL) have embedded procedural languages that can handle almost arbitrary semantics of data.
Of course, being relational databases, they only support limited syntax (records and tables in their various representations), and definitions of structure and operation are implemented as a primitive, hard to use language (SQL) however principles of their design can be applied to more complex data structures as well. It's really a shame when ancient monstrosity such as SQL can be given as an example of superior design compared to supposedly modern and advanced infrastructure built around XML.
You can't because application level semantics are always handled by the implementation. If you write a custom format/parser you can deal with these issues during the parsing phase, but it doesn't remove the fact that this is an implementation level feature.
That depends entirely on the languages involved. All parsers pass their data to semantics handling routines in some form. Nothing prevents a parser to have interface to semantics handling defined in some language (same or other than the language of the application) that implements all semantics-related parts of the standard. Then this semantics definition can be included as a part of standard, as opposed to being a part of implementation that only has to work with one piece of software, and programmers will have to keep it as defined in the standard (though implementation may transform it into a form that is compatible with application's language and interface) to have their implementations compliant.
For example, if the message contains a tree data structure that is meant as an update to the data defined as a graph (what is a common application of XML now), standard has to include a definition of all operations that may have to be done when it arrives, including lookup and update, consistency check, etc. The actual implementation that will perform those things in application may be generated from it, and may be extended to perform more data handling, however if standard says that it updates a graph, it has to define how exactly. Then there won't be "BUT WE DIDN'T REALLY MEAN THIS!" and "WHO WOULD THINK THAT SUCH A THING MAY HAPPEN?" from format developers every time it is discovered that standard is ambiguous, impossible, or standard document contradicts with standard originator's own implementation.
That would be worthy of being called "infrastructure".
I don't think anyone is arguing that XML is well designed or fast. But until some other format offers you the ability to express validation rules in as nuanced a way as XSD and manages to get the format standardized to the point where everyone can be expected to understand it, it's all we have.
Validation is a worthless waste of time. It will not help you if you have received a message with invalid data and valid format, and it will not help you to develop a procedure that can only produce valid format -- you can only test finite number of generated messages/documents, and therefore will never be sure that your system will not fail.
You don't need validation, you need a mechanism that produces two matching procedures -- one that is guaranteed to generate valid format, another that is guaranteed to parse it. As long as those procedures support the same standard (what may have to include support for forward and backward compatibility -- "format" may be pretty complex), are resistant to deliberately invalid data (so they will produce meaningless output or error but won't crash or overuse resources), and can be used on all platforms and languages that may need to handle this format, you can rely on the system built with them.
Please note that I consider meaningless output in response to invalid data to be a perfectly acceptable outcome because application that can be exposed to potentially malicious or corrupt data must support some trust/security model and consistency checks that will prevent damage when invalid data arrives regardless of that data being properly or improperly formatted. All protocol and format have to do is not to contain their own vulnerabilities. It does not matter how compatibility is achieved -- procedures may be generated from meta-language, they may be written manually and proven to be correct, or they may call some library that parses data according to meta-language. The point is, there should be no theoretical possibility of producing mismatched data producer and consumer. You don't write something, then run it and check if you were lucky, and it miraculously happened to produce a format that passes validation. You make something YOU CAN PROVE to be incapable of producing invalid data or mis-parsing valid one.
XML standard developers did not understand those most fundamental things that have to be considered when someone writes software that produces an output in some language.
If you want to pretend that Wikipedia is a valid source for learning about ancient agricultural practices, at least try to follow the links to some most relevant concepts mentioned in the article.
XML is a system of grammar that is used to create defined formats.
...made for people who slept through compiler courses.
You can't use XML to markup data. You have to use a defined grammar to create a format. You might say that this is an issue of semantics but that is the point. If your only use/understanding of XML is as a static data format then your doing it [XML/XSLT/..] wrong.
No, you can't "create" a format with XML. To "create" anything but the most trivial formats you have to provide a definition of both syntax and semantics. XML provides ridiculously complex, stupidly designed means to define a syntax, and absolutely nothing to define semantics, so you still have to either document it or, more likely, provide an implementation.
Guess what? The syntax is such a microscopic part of your task, the amount of work you have just placed into your reference implementation of semantics is multiple orders of magnitude higher than whatever you "saved" by not implementing syntax parser from scratch, leave alone implemented it using any tools that existed long before XML was introduced. The problem is, people who "learn XML" never learn how dead simple parsing in general is, so they use those "frameworks" and "tools" to save what otherwise would be literally seconds of their mental work.
I am not against simplifying further tasks that are already simple if it serves any valid purpose. The problem with XML, it does not really simplify anything, it provides ridiculously amateurish solution for a common easy problem without even a slightest attempt to help with truly complex part of work.
XML is crappy tool for static storage. If the data is being read/written by the same program there are faster/simpler was to encode that data. But that isn't what XML is meant for. To repeat my previous post; XML documents are abstracted semantic models that are designed to be transformed and dynamically interpreted.
Words "XML", "abstract" and "semantic" do not belong in the same phrase -- XML is developed at the level of a second-year CS student who managed to completely miss what "abstract" and "semantics" mean. It's not "abstract", it's artificial and irrelevant. The only value of XML is the fact that it's some standard, however this does not change the fact that it's nearly the worst possible solution for any imaginable problem.
Here is a link to an example of how XML/XSLT can be used to extend and enhance an existing XML based web service [Generating RSS with XSLT and Amazon ECS]. This a perfect example of the agnostic client scenario that XML was designed for (ie: the service could care less how the data is represented or transformed).
Have you read anything I wrote? XML is useful for interoperability with things that already use XML, and for making representation of pretty pictures/UI. This has nothing to do with the fact that it's crap, and that we all will be better off if with a standard created by someone competent. For the values of "competent" as in "anyone who actually studied CS".
1. What is the actual rate of undetected corrupt (not lost -- those are reliably detected) packets that reach TCP layer, and how it compares with undetected error rate of those computers' RAM? We are not just dealing with extremely small, even though nonzero probabilities -- it's a multiplication of very small probabilities.
2. If you really have computer so reliable that you have to worry about magically checksum- matching TCP packet corruption, syntax check is the wrong tool for the job -- those errors are very unlikely to show up in XML as invalid syntax, so XML validation is still completely pointless for them. You need either a tunnel/VPN that will detect an error when packet or TCP stream is forwarded to the local host or network, or application-level data validation, what is beyond the scope of XML.
This is, of course, a solution for the paranoid. Its practical usefulness is about at the same level as planning a defense against an army of ninjas attacking the data center -- after all, probability of that is nonzero, too.
He wasn't convicted without evidence. He was convicted without a body. The evidence may have been largely circumstantial, but there was a great deal of it, and it was strong.
No. There was a lot of evidence, the problem was, all that evidence was total crap. You can find about the same amount of evidence linking me (or yourself) to any random crime that happened in close proximity -- and the more time you spend the more you can find. Obviously the problem is, it does not prove anything because if you change the direction of your search you can find just as much supposedly incriminating any other person that was in the same area when the crime happened. It was clear that police came to conclusion that Hans killed Nina, and then focused all investigation on digging things they can use against Hans -- throwing crap against the wall in the hope that some will stick. Regardless of their guess being lucky or unlucky, this is a total abandonment of their duty -- to investigate everything relevant to the crime and seek the truth in honest and competent manner.
No wonder, Oakland has horrendous amount of crime.
Data corruption in a communications link (e.g., this series of tubes we're using)
This should never reach the application -- in practice the probability of it less than the probability of undetectable hardware failure that would crash the system. Even if it does happen, program has to perform its own buffer limits management to prevent crash because of overused resources -- and that can happen much earlier than any format error will be found.
Data corruption in a storage medium (e.g., hardware hiccup, bit flip due to cosmic ray)
Applications should NEVER try to recover from it. There is higher probability that application code or internal data structures are damaged, so more code == more opportunities to crash. ECC hardware handles this already, and if ECC did not detect it, there are higher chances that your application will cause less damage by crashing than by trying to do any error handling while its internal code or data are corrupt.
Version differences between sender and receiver conception of the data format
This should implemented as a part of format/protocol, just like each and every protocol that was ever used over the Internet. Receiver should never try to second-guess the sender and vice-versa -- if there is a backward compatibility built into protocol, it should not rely on validation. If there isn't, session should fail immediately. SMTP does that cleanly. HTTP does that cleanly. Freaking Telnet does that cleanly. There is absolutely no excuse to rely on invalid data to detect version-dependent changes.
Malware that pretends to be a legitimate sender but, instead, sends invalid data
Secure protocol design is a veru well-researched area. XML is not designed according to its guidelines in the first place, validation of invalid data is often a great DoS target in itself.
The mere fact that you mention those issues mean that you are unfamiliar with general principles of network protocol design that were developed over decades of theoretical development and practical use. Same applies to people who developed XML.
Precisely. Decomposable formats, like XML, allow programs to have semantics for part, but not all, of a data structure. Non-decomposable formats, like C structs, require semantics for all of a data structure. In situations where you know 100% of all use cases for a data structure, non-decomposable formats are fine. If, however, you want to allow for what Jonathan Zittrain refers to as "generativity" (i.e., unanticipated uses for existing technology as a means of advancing said technology), decomposable formats can be a benefit.
No. You don't just abandon the task of handling semantics. YOU CREATE A LANGUAGE to describe semantics. What is not difficult as long as you keep within appropriate language model. The problem is, judging by XML designers' ignorance about parsers, language design was far beyond their intellectual capabilities. What goes back to my point -- XML was developed by incompetent people, for wrong reasons, and based on assumptions that were known to be incorrect long before this monstrosity was developed.
Take, for example, ODT vs. classic binary Word documents, which are pretty much just a serialization of a big-ass binary structure as I understand it. I've written programs that parse and generate ODT, or, more precisely, the portions of ODT that I need. Frankly, I don't care what the rest of it is, so long as my generated documents work properly. And I didn't need to refer to the ODT documentation on OASIS or anything to write them, as the XML was sufficiently human-readable that, accompanied with experimentation, I was able to determine how to generate valid ODT. With Word, even if there were OOXML-sized documentation for it, I'd have to hand-roll my own parser for the whole damn format, just to pick out the pieces I need to work with. Now, if I worked for Microsoft on the Wo
Slashdot Mirror
1. Apparently no one but you was able to reproduce suspend/resume problem, and after your laptop was broken there was nothing to test. What the Hell did you expect? Very likely the problem is tied to specific BIOS, ACPI configuration or hardware release version, what you never bothered to test. Also no attempts to check how behavior changes if you force unloading driver before suspend/reloading after resume.
2. I have no idea why X11 is brought up in discussion -- by your description it looks like the problem does not happen in X.
Plenty of graphics adapters are unsupported by native framebuffer drivers, so everyone uses vesa or text mode for those. No modern general-purpose Linux program uses framebuffer for graphics directly, so unless your adapter is unsupported by X drivers, all you have lost is boot splash. Boo-hoo.
Where do I send my complaints?
To your manager -- about giving you a better job than trolling Slashdot.
It's to the point that there are only 3 types of Linux progs that work: the one that comes with the system (and its updates), the simple "./configure; make; make install" and the kind I write myself.
What is this mysterious other kind of application that exists for Linux? I am using it since 1994, and have yet to find the other kind.
Unless you mean, commercial binary packages, that I have never seen failing unless I intentionally mess with them far beyond their intended flexibility, what would break them on any OS.
No.
1. Distributions are binary-incompatible across DISTRIBUTION-PROVIDED software. Third-party software usually runs on everything, ex: binaries of Firefox, Adobe Reader, Flash, etc.
2. All distributions have their build procedure published. Supporting a distribution is a matter of following simple build directions.
Of course, being completely unaware of anything even remotely related to development for Linux, you didn't know that, and therefore were repeating the words of your friendly Microsoft marketing person.
it's things like slightly shifted terminal console,
Only happens on NON-LAPTOP computers with analog LCD monitors (solution: press "Auto-Adjust" and "Save" on your monitor while console text is displayed).
no sound after resuming from hibernation
Only happens on LAPTOP computers (who hibernates a desktop?, solution: update BIOS to a non-broken version).
Now, please, tell me, how did you encounter both "problems" at the same time, and if they aren't in fact the result of a google search for "linux problem"?
I have addressed precisely this stupidity in this response.
Who in this case happens to be Jeremy Allison.
What the Hell are you talking about? Jeremy Allison "endorsed" some modern amateurish criticism (and my whole point is that such an "endorsement" is stupid, be it by Jeremy Allison or anyone else).
I am referring to the Unix Haters Handbook, similar text that was published 14 years ago and since then shown itself to be completely worthless for any purpose other than promoting the use of Windows to ignorant people.
First we had Ubentu Hardy Herring installed it for the most part worked however the Wireless card wouldn't work with WPA2 connection (other connection worked fine) So I had to downgrade to 7.10 and Wireless worked.
So you have downgraded to an obsolete version just because Network Manager or your card's driver for some reason did not automatically recognize your WPA2 network? Instead of, umm, replacing either of those components with one that works? And you claim that you used various OS, including Linux, before. Just how stupid are you?
I am typing this on a laptop with Ralink wireless card. Running Ubuntu Hardy. Network Manager does not work with it, either -- RutilT does, and that was the only thing I had to add.
...usually because they tried to compete with a free Linux application. The application may be useful, but many potential users don't see a benefit because they already have something that suits their needs, so the only people who buy it are ones who need precisely this application.
Extreme example: whose bright idea was to make Nero for Linux when K3B is far, far superior?
Unrelated to this, I doubt that many companies actually count sales by platforms -- licenses are usually portable between platforms, so purchaser for the company may ask for a license file checking "Windows" then the actual user installs a Linux binary. Recently I had to download one very expensive package for Windows just to get a Java-dependent installer to run (Linux packaging was hopelessly broken), then run the actual package (that included Linux binaries) exclusively on Linux. All, of course, complying with the license that was for one copy on either platform.
I can only add to it that "Unix Haters Handbook", ancient as it is, contained absolutely no information that was in any way useful for improving Unix or Unix-like systems -- the supposed flaws were either nonexistent, or became irrelevant after natural progress of technology.
It's especially easy to see on example of X11. OSX went into NeXT-like direction of replacing X, Windows as usual continued pushing DirectX and made yet another two layers above and below everything, Linux developers continued with Xorg/freedesktop.org direction. Current status: X kept all its advantages even after adding all infrastructure for widgets and high-level UI support, and all the eye candy from OpenGL and Composite, Windows Vista UI improvements seem to be mostly successful at wasting resources and irritating users, OSX added clumsy (tvwm-like at best) multiple desktops in latest version, and has no remote capabilities beyond VNC.
Apparently "over-engineered" X11 design was the right thing to do all along -- only Xaw and Motif really had to be abandoned, but that was not something that cheerful "Unix hater" would tell you from his comfy office on Redmond.
So no, this "criticism" is a worthless waste of time. Real users see real problems, ideology warriors write holy books decrying their enemies supposed deficiencies.
Except, of course, this is not how Debian packages work, and therefore you are posting bullshit.
lol wut
Normally you have this right even without EULA.
Blizzard can claim that they wouldn't sell you the copy if you didn't agree to EULA, however this is a pretty idiotic reasoning considering that you are not presented with EULA at the time of purchase.
The only thing Blizzard can do is to deny their service to those who don't agree to EULA, or break it after accepting -- after all, service contract is all that matters here, game is useless without the service. The problem is, Blizzard has no technical capability to do so (they can't stand behind each user's back, so they would be able to determine if he does or doesn't violate their license), and therefore makes ridiculous claims about scope of their rights.
GPL can't prevent you from using the program in whatever way you wish to use it or modify it. It can only deprive you from the right to distribute it or anything based on it (what copyright actually covers, and GPL grants to the recipient).
Oh, great, your "tags" broken the quoting.
You might have not noticed, but it's not just XML. Almost everyone has moved to Unicode now, and those who haven't yet (Ruby, PHP) are being mocked for just that, and have the move on the top of their TODO. Learn to live with it already.
Actually no. I know because I am Russian.
You are extremely confused here. Neither of these: "capitalization procedure, spellchecker, hyphenation, phonetic match, acronym expansion, index sorting" - has anything to do with charset or encoding; none whatsoever. This is because encoding has nothing to do with a language. UTF-8 is an encoding which can handle hundreds of languages. Latin-1 is another one that can handle perhaps several dozen. Windows-1251, IIRC, can handle both Russian and Belarusian. It really does not matter. What matters is the language of the text and the associated culture (aka "locale") - trying to infer it from encoding or charset is silly and, in the end, futile.
"Locale" is NEVER about handling of data, only about presentation of it to the user and locally defined elements of user interface. Language in a document has to be always handled in exactly the same way as long as it's the same language, regardless of what user's settings are. There may not even be a "user" or "locale" for non-interactive data processing. People suffered more than enough with "locale" settings in databases mangling their data already.
And, surprise surprise, XML has a standard mechanism to associate content of an element with a specific language - it's xml:lang attribute. So, whenever you write, for example, an XHTML document that contains both English and Russian, all you need is to surround parts of texts in another language with span or div, and mark them with xml:lang. It's even specifically mentioned in the XHTML spec.
Apparently you haven't read what I wrote.
XML "allows" to handle languages. The problem is, it does not force implementors to handle them because it allows an easy shortcut. And implementors who knew nothing about language metadata that may be relevant (pretty much all of people who pushed for Unicode in the first place) didn't feel an obligation to support any kind of language-dependent processing. If the standard forced them to handle multiple charsets, they would not be able to create this fake language support -- at the moment the application encountered anything beyond their beloved ISO-8859-1 (what would be 99% of "Unicode" documents those people seen), it would have to perform some metadata-dependent text handling -- for both charset and language. Application would have two choices -- never assume anything about a language and pass data transparently, or call charset/language-dependent handling for everything they do that may be dependent on charset and language. Since this wasn't done, at this point not a single piece of software actually supports multiple languages in a way that XML and Unicode-promoters promised. Not OpenOffice.org, not Microsoft Office, not text input in any UI toolkit, not mailreaders, not databases. Every time someone implements a particular language support or common support for multiple languages, it has to be done in a way that breaks the intended model of metadata handling in XML, and imposes "special" rules on Unicode ranges that have nothing to do with Unicode standard.
You may claim that those are all crappy implementations, however my point is, the standard was specifically designed to allow developers hide behind pretty pictures that look like text is "foreign" languages -- except really there is no language support whatsoever.
You might have not noticed, but it's not just XML. Almost everyone has moved to Unicode now, and those who haven't yet (Ruby, PHP) are being mocked for just that, and have the move on the top of their TODO. Learn to live with it already.
Actually no. I know because I am Russian.
You are extremely confused here. Neither of these: "capitalization procedure, spellchecker, hyphenation, phonetic match, acronym expansion, index sorting" - has anything to do with charset or encoding; none whatsoever. This is because encoding has nothing to do with a language. UTF-8 is an encoding which can handle hundreds of languages. Latin-1 is another one that can handle perhaps several dozen. Windows-1251, IIRC, can handle both Russian and Belarusian. It really does not matter. What matters is the language of the text and the associated culture (aka "locale") - trying to infer it from encoding or charset is silly and, in the end, futile.
And, surprise surprise, XML has a standard mechanism to associate content of an element with a specific language - it's xml:lang attribute. So, whenever you write, for example, an XHTML document that contains both English and Russian, all you need is to surround parts of texts in another language with or
, and mark them with xml:lang. It's even specifically mentioned in the XHTML spec.
Apparently you haven't read what I wrote.
XML "allows" to handle languages. The problem is, it does not force implementors to handle them because it allows an easy shortcut. And implementors who knew nothing about language metadata that may be relevant (pretty much all of people who pushed for Unicode in the first place) didn't feel an obligation to support any kind of language-dependent processing. If the standard forced them to handle multiple charsets, they would not be able to create this fake language support -- at the moment the application encountered anything beyond their beloved ISO-8859-1 (what would be 99% of "Unicode" documents those people seen), it would have to perform some metadata-dependent text handling -- for both charset and language. Application would have two choices -- never assume anything about a language and pass data transparently, or call charset/language-dependent handling for everything they do that may be dependent on charset and language. Since this wasn't done, at this point not a single piece of software actually supports multiple languages in a way that XML and Unicode-promoters promised. Not OpenOffice.org, not Microsoft Office, not text input in any UI toolkit, not mailreaders, not databases. Every time someone implements a particular language support or common support for multiple languages, it has to be done in a way that breaks the intended model of metadata handling in XML, and imposes "special" rules on Unicode ranges that have nothing to do with Unicode standard.
You may claim that those are all crappy implementations, however my point is, the standard was specifically designed to allow developers hide behind pretty pictures that look like text is "foreign" languages -- except really there is no language support whatsoever.
I should have been clearer and said 'non-database'... But yes you are correct a formal relational database is great way to store static information it can automatically enforce it's schema and basic semantic integrity. Anyone who uses XML as a replacement for a database is using to much of it. Like I've stressed before XML is a poor format for static data storage. If the data isn't going to be transformed, aggregated, filtered, or translated at some time in the future; then XML may not be best choice for storage. To state it differently: XML is meant to be used for transportation vs. storage of data.
Databases are tied to a single data model, and their access protocols are not designed for efficient bulk data transfer. The major justification for XML (and all its possible replacements) was support for data that is not limited to a relational data model.
Essentially what you are describing is IDL with a touch of COM.
IDL is primitive, and COM ties general semantics to particular application's implementation and does not translate beyond it without a manual reimplementation. Neither counts as a formal semantics definition.
This a big shift in program design (specifically what constitutes a 'program'). Instead of monolithic code bases you have distributed servlets and transformation processes. A 'program' can be an abstracted service or it could be the description of the processing and filtering chain combining the resources of third party data sources and services.
Commingling of data format and consistency support with implementation-specific logic is a design deficiency, not a requirement for data consistency support.
It called documentation...
Documentation is informal -- it requires a human to interpret and implement, and it almost never gives unambiguous definition for all possible behaviors that can be expected from a system. If you look at any documentation that accompanies XML-based formats, it's a huge mass of words that can mean pretty much anything, and this is the root of all incompatibility.
To make a system reliable, formats have to be defined formally, and all behavior has to be reflected in an unambiguous way. Then even if behavior is not what a programmer wants or expects, he can be sure what it actually is.
No, Oakland has a horrendous amount of crime because it has a horrendous amount of criminals. You don't live around here, do you?
Actually I do live around there. Last time I checked, criminals are not a part of indigenous flora or fauna -- they flourish wherever there are conditions conducive to crime. A combination of poverty, shitty city planning, and as we see by this example incompetent law enforcement definitely counts as "conducive to crime".
The car with the passenger's seat removed and the floor wet as if it had been washed, found on an Oakland street yet not reported stolen
I guess, It was not reported stolen because it wasn't stolen. Thousands of people leave their cars on the streets in conditions far worse and weirder than that -- should we round them up and prosecute for the nearest recent unsolved crime?
Nina's vehicle, also found on an Oakland street but not reported stolen
That would be consistent with any kind of sudden disappearance except one (if she left Oakland in her van). Nothing links it to Hans.
The blood
I happen to own a laptop bag drenched in blood. What actually is related to an unsolved crime and unusual behavior of some people. Nevertheless I am most definitely alive, and did not kill anyone.
The fact that he was the last person known to have seen her alive
If that qualified as a proof, we would be able to just convict the last person who had seen each and every victim of unsolved murder.
His testimony, which was probably more damning than much of the other evidence. OK, I think his testimony was crap too, and from a getting away with it perspective he was an idiot to take the stand, but I don't think it was crap the way you think it was crap. You seem to have believed him. Maybe you still believe him, even though he has now confessed and her body has been found.
Actually the only thing his testimony is good for is to confirm that he is not a social person, and that he was scared when police was obviously hounding him. What was known from the very beginning. I know plenty of people who behave in a similar manner, none of them committed an offense worse than speeding. If people were imprisoned based on those things alone, there would be, among other things, a lot of software without maintainers.
Or put another way, "if it walks like a duck and quacks like a duck..."
This is precisely what the presumption of innocence, burden of proof and various other fundamental concepts in law enforcement and justice supposed to prevent. Despite the fact that often such a guess is actually correct. Police and prosecution have to provide a proof, something that excludes the possibility that there was a peculiar combination of circumstances and misdirection that merely suggests someone's guilt. And in case of this murder they had ample opportunity to do so by collecting evidence, excluding various other "colorful characters" involved, not messing up collection of blood from the house, interviewing kids in a manner appropriate for the situation, making more of an effort to find the body and, of course, not spending weeks trying to prove that Hans was not a nice person (they would get essentially the same information from LKML archive).
Instead police and prosecution relied entirely on lucky guesses and random smear campaign in front of jury composed of people unfamiliar with antisocial nerds such as Hans. That sloppy police work, strategy of investigation and prosecution that chases after low-hanging fruit and does not doubt superficial impressions, goes a long way explaining why you have to be a mathematician to be prosecuted for a serious crime in Oakland. What is also not an actual proof but merely a plausible explanation of the fact that non-nerdy criminals terrorize Oakland with impunity.
For the record, there is nothing I like more than writing custom parsers its hella fun! That being said; I have things to do other than watch Matlock and write parsers for no good reason (it's like knitting for DPD-11 crowd).
Parsers are generated by automated tools. To be precise, XML parsers are among few exceptions that are not generated.
Your argument about implementation is a red herring. If by semantics you are refering to application-level semantics then yes you have to provide an implementation. Show me a file-oriented data storage method that automatically handles application level semantics.
Any modern relational database has minimal semantics support -- it allows to define constraints, references and indexes that reflect application semantics as well as table structure that reflect syntax. Some databases (ex: Oracle, PostgreSQL) have embedded procedural languages that can handle almost arbitrary semantics of data.
Of course, being relational databases, they only support limited syntax (records and tables in their various representations), and definitions of structure and operation are implemented as a primitive, hard to use language (SQL) however principles of their design can be applied to more complex data structures as well. It's really a shame when ancient monstrosity such as SQL can be given as an example of superior design compared to supposedly modern and advanced infrastructure built around XML.
You can't because application level semantics are always handled by the implementation. If you write a custom format/parser you can deal with these issues during the parsing phase, but it doesn't remove the fact that this is an implementation level feature.
That depends entirely on the languages involved. All parsers pass their data to semantics handling routines in some form. Nothing prevents a parser to have interface to semantics handling defined in some language (same or other than the language of the application) that implements all semantics-related parts of the standard. Then this semantics definition can be included as a part of standard, as opposed to being a part of implementation that only has to work with one piece of software, and programmers will have to keep it as defined in the standard (though implementation may transform it into a form that is compatible with application's language and interface) to have their implementations compliant.
For example, if the message contains a tree data structure that is meant as an update to the data defined as a graph (what is a common application of XML now), standard has to include a definition of all operations that may have to be done when it arrives, including lookup and update, consistency check, etc. The actual implementation that will perform those things in application may be generated from it, and may be extended to perform more data handling, however if standard says that it updates a graph, it has to define how exactly. Then there won't be "BUT WE DIDN'T REALLY MEAN THIS!" and "WHO WOULD THINK THAT SUCH A THING MAY HAPPEN?" from format developers every time it is discovered that standard is ambiguous, impossible, or standard document contradicts with standard originator's own implementation.
That would be worthy of being called "infrastructure".
I don't think anyone is arguing that XML is well designed or fast. But until some other format offers you the ability to express validation rules in as nuanced a way as XSD and manages to get the format standardized to the point where everyone can be expected to understand it, it's all we have.
Validation is a worthless waste of time. It will not help you if you have received a message with invalid data and valid format, and it will not help you to develop a procedure that can only produce valid format -- you can only test finite number of generated messages/documents, and therefore will never be sure that your system will not fail.
You don't need validation, you need a mechanism that produces two matching procedures -- one that is guaranteed to generate valid format, another that is guaranteed to parse it. As long as those procedures support the same standard (what may have to include support for forward and backward compatibility -- "format" may be pretty complex), are resistant to deliberately invalid data (so they will produce meaningless output or error but won't crash or overuse resources), and can be used on all platforms and languages that may need to handle this format, you can rely on the system built with them.
Please note that I consider meaningless output in response to invalid data to be a perfectly acceptable outcome because application that can be exposed to potentially malicious or corrupt data must support some trust/security model and consistency checks that will prevent damage when invalid data arrives regardless of that data being properly or improperly formatted. All protocol and format have to do is not to contain their own vulnerabilities. It does not matter how compatibility is achieved -- procedures may be generated from meta-language, they may be written manually and proven to be correct, or they may call some library that parses data according to meta-language. The point is, there should be no theoretical possibility of producing mismatched data producer and consumer. You don't write something, then run it and check if you were lucky, and it miraculously happened to produce a format that passes validation. You make something YOU CAN PROVE to be incapable of producing invalid data or mis-parsing valid one.
XML standard developers did not understand those most fundamental things that have to be considered when someone writes software that produces an output in some language.
If you want to pretend that Wikipedia is a valid source for learning about ancient agricultural practices, at least try to follow the links to some most relevant concepts mentioned in the article.
Such as http://en.wikipedia.org/wiki/Slash_and_burn
XML is a system of grammar that is used to create defined formats.
...made for people who slept through compiler courses.
You can't use XML to markup data. You have to use a defined grammar to create a format. You might say that this is an issue of semantics but that is the point. If your only use/understanding of XML is as a static data format then your doing it [XML/XSLT/..] wrong.
No, you can't "create" a format with XML. To "create" anything but the most trivial formats you have to provide a definition of both syntax and semantics. XML provides ridiculously complex, stupidly designed means to define a syntax, and absolutely nothing to define semantics, so you still have to either document it or, more likely, provide an implementation.
Guess what? The syntax is such a microscopic part of your task, the amount of work you have just placed into your reference implementation of semantics is multiple orders of magnitude higher than whatever you "saved" by not implementing syntax parser from scratch, leave alone implemented it using any tools that existed long before XML was introduced. The problem is, people who "learn XML" never learn how dead simple parsing in general is, so they use those "frameworks" and "tools" to save what otherwise would be literally seconds of their mental work.
I am not against simplifying further tasks that are already simple if it serves any valid purpose. The problem with XML, it does not really simplify anything, it provides ridiculously amateurish solution for a common easy problem without even a slightest attempt to help with truly complex part of work.
XML is crappy tool for static storage. If the data is being read/written by the same program there are faster/simpler was to encode that data. But that isn't what XML is meant for. To repeat my previous post; XML documents are abstracted semantic models that are designed to be transformed and dynamically interpreted.
Words "XML", "abstract" and "semantic" do not belong in the same phrase -- XML is developed at the level of a second-year CS student who managed to completely miss what "abstract" and "semantics" mean. It's not "abstract", it's artificial and irrelevant. The only value of XML is the fact that it's some standard, however this does not change the fact that it's nearly the worst possible solution for any imaginable problem.
Here is a link to an example of how XML/XSLT can be used to extend and enhance an existing XML based web service [Generating RSS with XSLT and Amazon ECS]. This a perfect example of the agnostic client scenario that XML was designed for (ie: the service could care less how the data is represented or transformed).
Have you read anything I wrote? XML is useful for interoperability with things that already use XML, and for making representation of pretty pictures/UI. This has nothing to do with the fact that it's crap, and that we all will be better off if with a standard created by someone competent. For the values of "competent" as in "anyone who actually studied CS".
Really?
1. What is the actual rate of undetected corrupt (not lost -- those are reliably detected) packets that reach TCP layer, and how it compares with undetected error rate of those computers' RAM? We are not just dealing with extremely small, even though nonzero probabilities -- it's a multiplication of very small probabilities.
2. If you really have computer so reliable that you have to worry about magically checksum- matching TCP packet corruption, syntax check is the wrong tool for the job -- those errors are very unlikely to show up in XML as invalid syntax, so XML validation is still completely pointless for them. You need either a tunnel/VPN that will detect an error when packet or TCP stream is forwarded to the local host or network, or application-level data validation, what is beyond the scope of XML.
This is, of course, a solution for the paranoid. Its practical usefulness is about at the same level as planning a defense against an army of ninjas attacking the data center -- after all, probability of that is nonzero, too.
He wasn't convicted without evidence. He was convicted without a body. The evidence may have been largely circumstantial, but there was a great deal of it, and it was strong.
No. There was a lot of evidence, the problem was, all that evidence was total crap. You can find about the same amount of evidence linking me (or yourself) to any random crime that happened in close proximity -- and the more time you spend the more you can find. Obviously the problem is, it does not prove anything because if you change the direction of your search you can find just as much supposedly incriminating any other person that was in the same area when the crime happened. It was clear that police came to conclusion that Hans killed Nina, and then focused all investigation on digging things they can use against Hans -- throwing crap against the wall in the hope that some will stick. Regardless of their guess being lucky or unlucky, this is a total abandonment of their duty -- to investigate everything relevant to the crime and seek the truth in honest and competent manner.
No wonder, Oakland has horrendous amount of crime.
Data corruption in a communications link (e.g., this series of tubes we're using)
This should never reach the application -- in practice the probability of it less than the probability of undetectable hardware failure that would crash the system. Even if it does happen, program has to perform its own buffer limits management to prevent crash because of overused resources -- and that can happen much earlier than any format error will be found.
Data corruption in a storage medium (e.g., hardware hiccup, bit flip due to cosmic ray)
Applications should NEVER try to recover from it. There is higher probability that application code or internal data structures are damaged, so more code == more opportunities to crash. ECC hardware handles this already, and if ECC did not detect it, there are higher chances that your application will cause less damage by crashing than by trying to do any error handling while its internal code or data are corrupt.
Version differences between sender and receiver conception of the data format
This should implemented as a part of format/protocol, just like each and every protocol that was ever used over the Internet. Receiver should never try to second-guess the sender and vice-versa -- if there is a backward compatibility built into protocol, it should not rely on validation. If there isn't, session should fail immediately. SMTP does that cleanly. HTTP does that cleanly. Freaking Telnet does that cleanly. There is absolutely no excuse to rely on invalid data to detect version-dependent changes.
Malware that pretends to be a legitimate sender but, instead, sends invalid data
Secure protocol design is a veru well-researched area. XML is not designed according to its guidelines in the first place, validation of invalid data is often a great DoS target in itself.
The mere fact that you mention those issues mean that you are unfamiliar with general principles of network protocol design that were developed over decades of theoretical development and practical use. Same applies to people who developed XML.
Precisely. Decomposable formats, like XML, allow programs to have semantics for part, but not all, of a data structure. Non-decomposable formats, like C structs, require semantics for all of a data structure. In situations where you know 100% of all use cases for a data structure, non-decomposable formats are fine. If, however, you want to allow for what Jonathan Zittrain refers to as "generativity" (i.e., unanticipated uses for existing technology as a means of advancing said technology), decomposable formats can be a benefit.
No. You don't just abandon the task of handling semantics. YOU CREATE A LANGUAGE to describe semantics. What is not difficult as long as you keep within appropriate language model. The problem is, judging by XML designers' ignorance about parsers, language design was far beyond their intellectual capabilities. What goes back to my point -- XML was developed by incompetent people, for wrong reasons, and based on assumptions that were known to be incorrect long before this monstrosity was developed.
Take, for example, ODT vs. classic binary Word documents, which are pretty much just a serialization of a big-ass binary structure as I understand it. I've written programs that parse and generate ODT, or, more precisely, the portions of ODT that I need. Frankly, I don't care what the rest of it is, so long as my generated documents work properly. And I didn't need to refer to the ODT documentation on OASIS or anything to write them, as the XML was sufficiently human-readable that, accompanied with experimentation, I was able to determine how to generate valid ODT. With Word, even if there were OOXML-sized documentation for it, I'd have to hand-roll my own parser for the whole damn format, just to pick out the pieces I need to work with. Now, if I worked for Microsoft on the Wo