TorgoX sburkeNO@SPAMcpan.org http://search.cpan.org/~sburke/ "Il est beau comme la retractilité des serres des oiseaux rapaces [...] et surtout, comme la rencontre fortuite sur une table de dissection d'une machine à coudre et d'un parapluie !" -- Lautréamont
I've always thought of tagging systems for data storage and interchange as wheels being re-invented left-and-right for every industry and purpose imaginable. SGML, EDI, CSV, etc.. Think back 10 years, 20 years, at what was being touted as the best way to exchange data with other companies. Of course the Y axis of basic ascii-ness of early computing systems was extended in various ways too for foreign alphabets as well (code pages, unicode, etc..).
XML strikes me as the combined second-system effect of a
XML strikes me as the combined second-system effect of all of the above.
Then I would say that Piers' question isn't so much important as much as it's the wrong question to ask.
XML is a perfectly acceptable solution for one very important problem: interoperability with data exchange. There's a benefit to not creating a new binary format for each and every fragment of information we want to author, exchange, archive or share. (There's even less of a benefit to shoving all of that data into XML and ca
I'd really s/XML/Java/g. Never seen such bloat in all my life. Their out-of-the-box standards seem to be about the size of CPAN whilst being a lot less comprehensible at the same time.
-Dom
Seconded. XML is an easy but lousy shot because while the horrible stuff is the part that gets the most PR (presumably because it needs it), there are lots of easy and elegant stuff being very useful under the radar.
Java on the other hand is exactly that. Take a complex Perl module implementing a horribly kludgy spec such as SOAP::Lite, and compare it in size, bloat, and ease-of-use with the supposedly state of the art Axis by the ASF.
And don't even get me started on what most Java programmer
XML as a second system (Score:1)
XML strikes me as the combined second-system effect of a
Re:XML as a second system (Score:2)
Then I would say that Piers' question isn't so much important as much as it's the wrong question to ask.
XML is a perfectly acceptable solution for one very important problem: interoperability with data exchange. There's a benefit to not creating a new binary format for each and every fragment of information we want to author, exchange, archive or share. (There's even less of a benefit to shoving all of that data into XML and ca
XML ain't great, but... (Score:2, Insightful)
Re:XML ain't great, but... (Score:3, Interesting)
Seconded. XML is an easy but lousy shot because while the horrible stuff is the part that gets the most PR (presumably because it needs it), there are lots of easy and elegant stuff being very useful under the radar.
Java on the other hand is exactly that. Take a complex Perl module implementing a horribly kludgy spec such as SOAP::Lite, and compare it in size, bloat, and ease-of-use with the supposedly state of the art Axis by the ASF.
And don't even get me started on what most Java programmer
-- Robin Berjon [berjon.com]