Regarding moving it around, check out the EBR-II project that served as the prototype of the Integral Fast Reactor design (and was killed in the early 90s before much useful data could be gathered). It was built around the concept of cheap, on-site enrichment so that transuranics never left the premises.
As for thin-film solar, stop dreaming. It ain't gonna happen. 1.367kW/m^2 is the maximum theoretical amount of energy we can get from the sun. Do the math on area required where we can power the 3.848 trillion kilowatt-hours the US consumed last year. Now factor in that the total US production of solar panels up to today equals about 11,000 square miles.
Sad as it is, the people of the US will never voluntarily reduce their energy usage substantially. Making assumptions on the possibility of successfully promoting conservation is a fool's errand. Yeah, wind. There are about 18,000 windmills in California. Know how many more we'd need to power California? More than a million. Not gonna happen.
Like it or not, nuclear is our best and perhaps soon only option.
Not at all like perpetual motion. One of the "waste" products of a light water reactor's fuel cycle is excess plutonium. Unfortunately, everything in a light water reactor is tailored to slowing the neutron flux down. Breeder/burner reactors are tailored toward fast neutron flux and can use plutonium in their fuel cycles.
Think of it as the efficiency difference between a fire at a campsite versus a modern wood-burning stove.
Yeah, perhaps we should put some money, resources and time into checking out how well they'd work out objectively. Perhaps set one up at the EBR-II nuclear test site. Oh wait! We actually did that. And just a couple of years before the study was completed, the program was killed during the Clinton administration and all research done up to that point -- which would have clearly told us where we stood in terms of science and technology -- was wasted.
Not breeder. Breeder reactors are bad as they end up producing more plutonium than they start with. What we need are fast neutron burner reactors. These consume more plutonium than they produce making them prime examples of ways to decommission old warheads and eliminating a large chunk of the spent fuel sitting in the pools and caskets....although I don't suppose "burner" has a particularly good connotation to it either. Perhaps we should call them "nuclear waste reduction plants". After all, that's what they are.
The state of the art when Carter was in office was the late 70s. I'd like to think that we've learned at least one or two things related to nuclear power in the last thirty years.
Perhaps because the current plans call for putting the material in dug out rock and then sealing them in with enormous amounts of concrete. Getting back to them later will be prohibitively difficult....but then, that was the point.
For one, most aquatic life is near the surface and close to coastlines. Second, no one that I know of is suggesting that we dump it without vitrification and some form of containment. Third, at a subduction zone the material will slowly be covered by sediment and take a trip to the Earth's mantle. Fourth, those are big oceans and the material we're talking about is not that big (the volume of a two-story house over the operating lifetime of a typical nuclear power plant). If the vitrified material was somehow dispersed over that wide an area, chances are that it's effects would be minimal -- widespread tuna sterility is highly unlikely.
Hell, if history is any guide, it might help marine populations. How? Look at Chernobyl. The wildlife there is flourishing in spite of widespread nuclear contamination. It turns out that humans continue to be the greatest threat to other life on this planet -- apparently far more so than even nuclear fallout.
And just to be clear, ocean dispersal is NOT the primary danger and not the reason for focusing on dryness. The worry about dryness is primarily due to contamination of fresh water tables and related aquifers. Ocean dispersal is at best a distant second.
Of course, this is all academic. We should be enriching the spent fuel so that most of it isn't waste, putting it into fast neutron burner reactors, and dealing with the resultant true waste materials which have significantly shorter halflives. Reduce the danger *and* get power from it so that we can start weaning ourselves off fossil fuels. Extreme containment measures aiming for tens or hundreds of thousands of years would no longer be necessary. Building storage that will last a couple hundred years is comparatively simple.
Halflives: Actinium-227 - 21.773 years (up to 218 years until rendered harmless) Actinium-225 - 10 days (up to 100 days until rendered harmless) Strontium-90 - 28 years (up to 280 years until rendered harmless)
Considering the volumes of these materials out of the total fuel cycle, I think we can store them safely. Then again, materials such as Actinium-227 are so radioactive, perhaps we can find a way to harness their energies productively as well.
Yes, because the US banning domestic enrichment for nuclear power has kept other countries from going nuclear (*cough* India, Pakistan, China, Israel, North Korea *cough*). Could someone please explain to me why domestic energy policy regarding enrichment is a proliferation risk? I don't get it. If you don't want it trading on the international market why not -- oh I don't know, let me throw out a possibility -- ban trade in materials reclaimed from spent fuel? Can you say, "Baby out with the bathwater"?
And handling concerns? How is keeping spent fuel in a pools, caskets, and eventual transport to remote Nevada mountains not already a handling concern?
Parent poster, this is not an attack on you. It's just that I consider US policy to be so incredibly foolhardy in this instance. Proliferation and handling need to get public scrutiny not get propped up as the boogyman that keeps up from working to solve the issues.
The fuel could be more valuable, too. For decades, industry and government officials have recognized that "spent" reactor fuel contains a large amount of unused uranium, as well as another very good reactor fuel, plutonium, which is produced as a by-product of running the reactor. Both can be readily extracted, although right now the price of new uranium is so low, and the cost of extraction so high, that reprocessing spent fuel is not practical. And the political climate does not favor a technology that makes potential bomb fuel--plutonium--an item of international commerce. But things might be different in 100 years. For starters, the same fuel could be reprocessed much more easily, since the potentially valuable components will be in a matrix of material that is not so intensely radioactive.
While the time waiting for it to cool off is a legitimate argument, the cost relative to mining uranium ore is not. Why? Because the costs for short-term and long-term storage have not been applied.
If you reduce the volume of waste by half, you have already saved a huge amount of money in the long run. Cooling pools are expensive. Spent fuel caskets are expensive. Homeland security measures for all the spent fuel is expensive. Yucca Mountain is ridiculously expensive. Reprocessing so that the fuel can be used again is cheap by comparison.
Fast neutron burner reactors. We've already got the waste, and burner reactors reduce the volume of waste while simultaneously producing large amounts of power thus reducing dependence on fossil fuels. Why is this even an issue anymore?
Because we're waiting for close to 100,000 square miles of solar cells or millions of new windmills to be built? Please!
1. Language does not determine speed. Algorithms do. 2. Zope can use a relational backend as well. It's just not as fast most of the time. 3. Caching is the key no matter what you use.
Try Queen's English to American English. As John Cleese once said when asked the difference between Americans and the English, "We speak English. You don't."
Bring in some colloquialisms from the South and compare them to the rhyming slang of parts of England and you'll have a closer analogy. Technically they are both speaking English, but there are massive differences that make communication quite difficult.
And as point of fact, my written and spoken English are quite similar. I haven't quite decided whether that means I have a particularly lucid form of writing, that my speech is more stilted or that most people just can't write for shit. In any event, your analogy was lost on me.
While C++ may have started as a preprocessed language on top of C, it has since continued to diverge to the point where it cannot be seen strictly as a superset anymore. In other words, it has been transitioning from being just a dialect to a noticeably different language with different traits and different idioms.
Also, be careful when you say such things as "I support both C and C++ compilers." It has the implication that you develop production compilers. If this was the case, you would have seen the tremendous difference in implementation between the two.
Yes and char* is a convention as well -- simply one agreed upon by the original C coders. Check out *any* article, book or note on C++ since 1998 by Stroustrop, Josuttis, Alexandrescu, etc. and you will see that char* is strongly discouraged in favor of std::string. The fact that it's part of the standard library is an implementation detail, not a comment on optional use.
With modern STL implementations, you have basically no advantage using char* or fixed size arrays in most code.
And the next time I see a job listing that asks for a "slavic speaker" or "bilingual romance and germanic", I'll let you know.
If C++ were a strict superset, standard practice wouldn't be to discourage use of char* in favor of std::string and fixed size arrays instead of std::vector.
The way you use the languages is often times quite different so it seems perfectly reasonable to me that one would differentiate between the two on their resume. OOP and generic programming anyone?
It's still scored funny because it's still true. If you are looking for any such comments, feel free to look in any discussion that includes database management systems. You'll see them. They're always there.
Because some of us would rather people used MS SQL Server than MySQL. That's how much some of us hate it. It isn't a proprietary vs. open source thing. It's a complete RDBMS vs. incomplete RDBMS thing.
And I'm not even talking about stored procedures. This is what I mean.
When MySQL starts getting strict, I will stop using it as my whipping boy and start -- as you say -- promoting it as one of the various open source solutions in general.
Now that MySQL users now talk about how much they enjoy their subselects, a feature which only a couple of years ago was being derided as just extra bloat, how long until 5.0 goes stable?
On that day, the hordes of MySQL developers will raise a chorus singing the praises of their new stored procedures, views and cursors. And behold! They didn't even slow down the product. Blessed be the MySQL programmers!
Until that day however, stored procedures are "useless" and "needlessly complex." The same with views and cursors. They only serve to slow things down. Of course those pesky naysayers of MySQL will point out that those features have been in PostgreSQL and Firebird for years. But no! Our golden calf does not yet support them in production and until it does they are obviously useless bloat.
Do you like it? I call this piece "Ode to a MySQL Fanboy."
Does Postgres still make really bad optimizer choices if the data-types being compared aren't identical? Last I checked.
At least there's a workaround. You can always explicitly cast your value to the type in question. I don't know of any similarly straightforward workarounds for the data manipulation/loss bugs in MySQL.
Forgot cursors. Silly me. And no, support in alpha code doesn't count. Until it can be put on a production server, it's a wishlist item, not a feature.
Notice, I never mentioned stored procedures, triggers, or views.
To me this doesn't say that the features aren't useful. It says that you prefer to use Oracle like people use MySQL. Doesn't surprise me really. Once you've written all the extra app layer functions that are needed with MySQL, you don't want to throw them away.
Even if a view/rule would have simplified the app layer from the start without adding substantial complexity to the database.
(By the way, just because you've never heard of someone moving from MySQL to PostgreSQL doesn't mean it doesn't happen. Check out the PostgreSQL mailing list archives. It is common to see questions from people migrating from MySQL.)
Stored procedures in no less than five different programming languages
Geometric/spatial datatypes and indexes
Real type safety
Errors when the alternative is data corruption
No silent failures
Enforcing a difference between NOT NULL and DEFAULT directives
Consistent foreign key enforcement (Target table must also be InnoDB, ON UPDATE does not allow recursive updates on the same table, out of range violations, brain dead implementation of NO ACTION)
Better transition to Oracle (closer feature parity)
Substandard transaction support (The time required to roll back a transaction increases in proportion with the number of operations performed during that transaction; Any non-InnoDB tables referenced in the transaction will not rollback)
And have they fixed the bug where CREATE INDEX, DROP INDEX, and most ALTER TABLEs rebuild the whole InnoDB table? It's been a year.
XML has unneeded complexity that does not give it more representational power - consider the brain-damaged distinction between attributes and sub-elements, or the way namespaces and DTD's sort-of kind-of interoperate.
I usually treat things as:
metadata = attribute
related content = sub element
You are right in that there are no hard and fast rules for what should be an attribute and what should be an element, but then I really haven't found it to be a real problem once I adopted the above.
DTDs do suck. I never plan on writing one again. XML Schema is too complicated for most applications. My personal favorite is RelaxNG which most popular parsers support now. Simple, easy to understand, and can also handle validation of data types.
XML is missing important stuff, and grafting that stuff in afterwards is painful - S-expressions at least have the idea of a number as a leaf element; you need XML Schemas to do that.
No, it follows the Principle of Least Power. XML by itself was never intended to have all of these other technologies built into the syntax by design. DTD vs. XML Schema vs. RelaxNG is a case in point. DTDs, a holdover from SGML, was never looked on fondly but it aided adoption by the SGML crowd. XML Schema was a standard by quarelling committee, and it shows. Folks wanted something as powerful but not as complex. Hence RelaxNG and its forebears were born. Note how this does not affect how XML documents look. An XML document I wrote back in 1999 can still be validated against a RelaxNG schema today.
And while you might think of this situation as fragmenting, please remember that use of DTDs does not disallow use of XML Schema or RelaxNG somewhere else in the chain. It allows for competition and best of breed to emerge. On the other hand, S-Expressions doesn't even have a bad standard schema language. It instead has hundreds. One schema language for almost each S-Expression schema. This is an improvement?
And while people may give namespaces a bad name, I happen to love them. Mixing document types without losing the ability to separate them again. Extensible validation. Is it perfect? Absolutely not. But what does S-Expressions have that's better or do you simply combine two documents and hope that you have no collisions?
XML is promoted as the data format that is going to solve all interoperability problems - witness the current Semantic Web hype.
Show me someone credible that claimed that. I don't ever recall Tim Berners-Lee ever saying that. I don't recall Jim Clark, Tim Bray or Mike Kay ever saying that. I don't recall any project managers from IBM, Microsoft or Apache ever saying that. I think you are characterizing the argument through the comments of wingnuts. That equals strawman.
XML doesn't solve all interoperability problems, however it helps with many interoperability problems. There is a major difference there, but because it cannot solve everything, some XML detractors don't want to use it for anything.
I will consider changing my.sig when I hear something about the Semantic Web that's more than hype, or I hear about a programming language that bottoms out in XML that anyone actually uses.
What do you mean by this? Bottom out as in is described in XML or bottoms out as in is serializable to XML or...?
S-expressions in Common Lisp can do arbitrary graphs within one "document", and this has worked since 1984. XML tries to do this with magic attributes (ID and IDREF, I think), which requires the application to recognize links in the DOM
Well of course. S-Expressions are serialized data structures. In the serialized form, S-Expressions do a similar thing. This is not a weakness of XML. (And for the record, ID and IDREF are types, not hardcoded attributes names.) If an
I doubt they would add Text and TextBuilder as they are. More likely, I could see them replacing the implementations of String and StringBuffer. Why add more classes when you can make the classes that people are already using much faster? What I'm wondering though is if there are technical reasons why this could not be done. Thread safety? Context in other classes?
As for Struct and Union, since Sun historically hasn't given a rat's ass about making interaction between Java and C or C++ (have you seen JNI?), I would be EXTREMELY surprised if they found their way into the standard libraries.
Dasher indeed looks interesting. The heuristics remind me of the input methods for Japanese keyboards where hiragana or katakana are entered, and depending upon the context, a short list of matching kanji is presented to choose from. Elegant solutions to a complex problem.
However, while Dasher can be compared to the JavaScript application that works with MathML, Dasher and MathML cannot be directly compared. Determining correctness would be from a program reading the DTD or schema of MathML. MathML would just be the serialized form (the data format).
(Not that I'm suggesting it be done but...) It's like saying that a C program would be written with prediction on raw parentheses and curly braces in the C source file. If anything, the predictive algorithm would be supplied with BNF notation. The C code would just be the output format.
I don't see why the technology associated with Dasher could not be applied to parsing DTD or schema files for output to XML syntaxes like MathML.
Slashdot Mirror
Regarding moving it around, check out the EBR-II project that served as the prototype of the Integral Fast Reactor design (and was killed in the early 90s before much useful data could be gathered). It was built around the concept of cheap, on-site enrichment so that transuranics never left the premises.
As for thin-film solar, stop dreaming. It ain't gonna happen. 1.367kW/m^2 is the maximum theoretical amount of energy we can get from the sun. Do the math on area required where we can power the 3.848 trillion kilowatt-hours the US consumed last year. Now factor in that the total US production of solar panels up to today equals about 11,000 square miles.
Sad as it is, the people of the US will never voluntarily reduce their energy usage substantially. Making assumptions on the possibility of successfully promoting conservation is a fool's errand. Yeah, wind. There are about 18,000 windmills in California. Know how many more we'd need to power California? More than a million. Not gonna happen.
Like it or not, nuclear is our best and perhaps soon only option.
Not at all like perpetual motion. One of the "waste" products of a light water reactor's fuel cycle is excess plutonium. Unfortunately, everything in a light water reactor is tailored to slowing the neutron flux down. Breeder/burner reactors are tailored toward fast neutron flux and can use plutonium in their fuel cycles.
Think of it as the efficiency difference between a fire at a campsite versus a modern wood-burning stove.
Yeah, perhaps we should put some money, resources and time into checking out how well they'd work out objectively. Perhaps set one up at the EBR-II nuclear test site. Oh wait! We actually did that. And just a couple of years before the study was completed, the program was killed during the Clinton administration and all research done up to that point -- which would have clearly told us where we stood in terms of science and technology -- was wasted.
Good on us.
Not breeder. Breeder reactors are bad as they end up producing more plutonium than they start with. What we need are fast neutron burner reactors. These consume more plutonium than they produce making them prime examples of ways to decommission old warheads and eliminating a large chunk of the spent fuel sitting in the pools and caskets. ...although I don't suppose "burner" has a particularly good connotation to it either. Perhaps we should call them "nuclear waste reduction plants". After all, that's what they are.
The state of the art when Carter was in office was the late 70s. I'd like to think that we've learned at least one or two things related to nuclear power in the last thirty years.
Perhaps because the current plans call for putting the material in dug out rock and then sealing them in with enormous amounts of concrete. Getting back to them later will be prohibitively difficult. ...but then, that was the point.
For one, most aquatic life is near the surface and close to coastlines. Second, no one that I know of is suggesting that we dump it without vitrification and some form of containment. Third, at a subduction zone the material will slowly be covered by sediment and take a trip to the Earth's mantle. Fourth, those are big oceans and the material we're talking about is not that big (the volume of a two-story house over the operating lifetime of a typical nuclear power plant). If the vitrified material was somehow dispersed over that wide an area, chances are that it's effects would be minimal -- widespread tuna sterility is highly unlikely.
Hell, if history is any guide, it might help marine populations. How? Look at Chernobyl. The wildlife there is flourishing in spite of widespread nuclear contamination. It turns out that humans continue to be the greatest threat to other life on this planet -- apparently far more so than even nuclear fallout.
And just to be clear, ocean dispersal is NOT the primary danger and not the reason for focusing on dryness. The worry about dryness is primarily due to contamination of fresh water tables and related aquifers. Ocean dispersal is at best a distant second.
Of course, this is all academic. We should be enriching the spent fuel so that most of it isn't waste, putting it into fast neutron burner reactors, and dealing with the resultant true waste materials which have significantly shorter halflives. Reduce the danger *and* get power from it so that we can start weaning ourselves off fossil fuels. Extreme containment measures aiming for tens or hundreds of thousands of years would no longer be necessary. Building storage that will last a couple hundred years is comparatively simple.
Halflives:
Actinium-227 - 21.773 years (up to 218 years until rendered harmless)
Actinium-225 - 10 days (up to 100 days until rendered harmless)
Strontium-90 - 28 years (up to 280 years until rendered harmless)
Considering the volumes of these materials out of the total fuel cycle, I think we can store them safely. Then again, materials such as Actinium-227 are so radioactive, perhaps we can find a way to harness their energies productively as well.
Yes, because the US banning domestic enrichment for nuclear power has kept other countries from going nuclear (*cough* India, Pakistan, China, Israel, North Korea *cough*). Could someone please explain to me why domestic energy policy regarding enrichment is a proliferation risk? I don't get it. If you don't want it trading on the international market why not -- oh I don't know, let me throw out a possibility -- ban trade in materials reclaimed from spent fuel? Can you say, "Baby out with the bathwater"?
And handling concerns? How is keeping spent fuel in a pools, caskets, and eventual transport to remote Nevada mountains not already a handling concern?
Parent poster, this is not an attack on you. It's just that I consider US policy to be so incredibly foolhardy in this instance. Proliferation and handling need to get public scrutiny not get propped up as the boogyman that keeps up from working to solve the issues.
While the time waiting for it to cool off is a legitimate argument, the cost relative to mining uranium ore is not. Why? Because the costs for short-term and long-term storage have not been applied.
If you reduce the volume of waste by half, you have already saved a huge amount of money in the long run. Cooling pools are expensive. Spent fuel caskets are expensive. Homeland security measures for all the spent fuel is expensive. Yucca Mountain is ridiculously expensive. Reprocessing so that the fuel can be used again is cheap by comparison.
Fast neutron burner reactors. We've already got the waste, and burner reactors reduce the volume of waste while simultaneously producing large amounts of power thus reducing dependence on fossil fuels. Why is this even an issue anymore?
Because we're waiting for close to 100,000 square miles of solar cells or millions of new windmills to be built? Please!
1. Language does not determine speed. Algorithms do.
2. Zope can use a relational backend as well. It's just not as fast most of the time.
3. Caching is the key no matter what you use.
Yes.
Try Queen's English to American English. As John Cleese once said when asked the difference between Americans and the English, "We speak English. You don't."
Bring in some colloquialisms from the South and compare them to the rhyming slang of parts of England and you'll have a closer analogy. Technically they are both speaking English, but there are massive differences that make communication quite difficult.
And as point of fact, my written and spoken English are quite similar. I haven't quite decided whether that means I have a particularly lucid form of writing, that my speech is more stilted or that most people just can't write for shit. In any event, your analogy was lost on me.
While C++ may have started as a preprocessed language on top of C, it has since continued to diverge to the point where it cannot be seen strictly as a superset anymore. In other words, it has been transitioning from being just a dialect to a noticeably different language with different traits and different idioms.
Also, be careful when you say such things as "I support both C and C++ compilers." It has the implication that you develop production compilers. If this was the case, you would have seen the tremendous difference in implementation between the two.
Yes and char* is a convention as well -- simply one agreed upon by the original C coders. Check out *any* article, book or note on C++ since 1998 by Stroustrop, Josuttis, Alexandrescu, etc. and you will see that char* is strongly discouraged in favor of std::string. The fact that it's part of the standard library is an implementation detail, not a comment on optional use.
With modern STL implementations, you have basically no advantage using char* or fixed size arrays in most code.
And the next time I see a job listing that asks for a "slavic speaker" or "bilingual romance and germanic", I'll let you know.
If C++ were a strict superset, standard practice wouldn't be to discourage use of char* in favor of std::string and fixed size arrays instead of std::vector.
The way you use the languages is often times quite different so it seems perfectly reasonable to me that one would differentiate between the two on their resume. OOP and generic programming anyone?
It's still scored funny because it's still true. If you are looking for any such comments, feel free to look in any discussion that includes database management systems. You'll see them. They're always there.
Because some of us would rather people used MS SQL Server than MySQL. That's how much some of us hate it. It isn't a proprietary vs. open source thing. It's a complete RDBMS vs. incomplete RDBMS thing.
And I'm not even talking about stored procedures. This is what I mean.
When MySQL starts getting strict, I will stop using it as my whipping boy and start -- as you say -- promoting it as one of the various open source solutions in general.
Now that MySQL users now talk about how much they enjoy their subselects, a feature which only a couple of years ago was being derided as just extra bloat, how long until 5.0 goes stable?
On that day, the hordes of MySQL developers will raise a chorus singing the praises of their new stored procedures, views and cursors. And behold! They didn't even slow down the product. Blessed be the MySQL programmers!
Until that day however, stored procedures are "useless" and "needlessly complex." The same with views and cursors. They only serve to slow things down. Of course those pesky naysayers of MySQL will point out that those features have been in PostgreSQL and Firebird for years. But no! Our golden calf does not yet support them in production and until it does they are obviously useless bloat.
Do you like it? I call this piece "Ode to a MySQL Fanboy."
Forgot cursors. Silly me. And no, support in alpha code doesn't count. Until it can be put on a production server, it's a wishlist item, not a feature.
Even if a view/rule would have simplified the app layer from the start without adding substantial complexity to the database.
(By the way, just because you've never heard of someone moving from MySQL to PostgreSQL doesn't mean it doesn't happen. Check out the PostgreSQL mailing list archives. It is common to see questions from people migrating from MySQL.)
- Schemas
- Views
- Rules
- Check constraints
- Domains
- Triggers
- Custom datatypes
- Stored procedures in no less than five different programming languages
- Geometric/spatial datatypes and indexes
- Real type safety
- Errors when the alternative is data corruption
- No silent failures
- Enforcing a difference between NOT NULL and DEFAULT directives
- Consistent foreign key enforcement (Target table must also be InnoDB, ON UPDATE does not allow recursive updates on the same table, out of range violations, brain dead implementation of NO ACTION)
- Better transition to Oracle (closer feature parity)
- Substandard transaction support (The time required to roll back a transaction increases in proportion with the number of operations performed during that transaction; Any non-InnoDB tables referenced in the transaction will not rollback)
And have they fixed the bug where CREATE INDEX, DROP INDEX, and most ALTER TABLEs rebuild the whole InnoDB table? It's been a year.And how about bugs like this (http://bugs.mysql.com/bug.php?id=5670) where creating an index destroys the table. Nice.
I usually treat things as:
metadata = attribute
related content = sub element
You are right in that there are no hard and fast rules for what should be an attribute and what should be an element, but then I really haven't found it to be a real problem once I adopted the above.
DTDs do suck. I never plan on writing one again. XML Schema is too complicated for most applications. My personal favorite is RelaxNG which most popular parsers support now. Simple, easy to understand, and can also handle validation of data types.
No, it follows the Principle of Least Power. XML by itself was never intended to have all of these other technologies built into the syntax by design. DTD vs. XML Schema vs. RelaxNG is a case in point. DTDs, a holdover from SGML, was never looked on fondly but it aided adoption by the SGML crowd. XML Schema was a standard by quarelling committee, and it shows. Folks wanted something as powerful but not as complex. Hence RelaxNG and its forebears were born. Note how this does not affect how XML documents look. An XML document I wrote back in 1999 can still be validated against a RelaxNG schema today.
And while you might think of this situation as fragmenting, please remember that use of DTDs does not disallow use of XML Schema or RelaxNG somewhere else in the chain. It allows for competition and best of breed to emerge. On the other hand, S-Expressions doesn't even have a bad standard schema language. It instead has hundreds. One schema language for almost each S-Expression schema. This is an improvement?
And while people may give namespaces a bad name, I happen to love them. Mixing document types without losing the ability to separate them again. Extensible validation. Is it perfect? Absolutely not. But what does S-Expressions have that's better or do you simply combine two documents and hope that you have no collisions?
Show me someone credible that claimed that. I don't ever recall Tim Berners-Lee ever saying that. I don't recall Jim Clark, Tim Bray or Mike Kay ever saying that. I don't recall any project managers from IBM, Microsoft or Apache ever saying that. I think you are characterizing the argument through the comments of wingnuts. That equals strawman.
XML doesn't solve all interoperability problems, however it helps with many interoperability problems. There is a major difference there, but because it cannot solve everything, some XML detractors don't want to use it for anything.
What do you mean by this? Bottom out as in is described in XML or bottoms out as in is serializable to XML or...?
Well of course. S-Expressions are serialized data structures. In the serialized form, S-Expressions do a similar thing. This is not a weakness of XML. (And for the record, ID and IDREF are types, not hardcoded attributes names.) If an
I doubt they would add Text and TextBuilder as they are. More likely, I could see them replacing the implementations of String and StringBuffer. Why add more classes when you can make the classes that people are already using much faster? What I'm wondering though is if there are technical reasons why this could not be done. Thread safety? Context in other classes?
As for Struct and Union, since Sun historically hasn't given a rat's ass about making interaction between Java and C or C++ (have you seen JNI?), I would be EXTREMELY surprised if they found their way into the standard libraries.
The linked article neglects to mention Unicode compatibility in its list, but a good read nonetheless.
Dasher indeed looks interesting. The heuristics remind me of the input methods for Japanese keyboards where hiragana or katakana are entered, and depending upon the context, a short list of matching kanji is presented to choose from. Elegant solutions to a complex problem.
However, while Dasher can be compared to the JavaScript application that works with MathML, Dasher and MathML cannot be directly compared. Determining correctness would be from a program reading the DTD or schema of MathML. MathML would just be the serialized form (the data format).
(Not that I'm suggesting it be done but...) It's like saying that a C program would be written with prediction on raw parentheses and curly braces in the C source file. If anything, the predictive algorithm would be supplied with BNF notation. The C code would just be the output format.
I don't see why the technology associated with Dasher could not be applied to parsing DTD or schema files for output to XML syntaxes like MathML.