Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

TorgoX (1933)

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

Journal of TorgoX (1933)

Tuesday April 08, 2003
06:40 PM

Wise words

[ #11534 ]
Dear Log,

An important question:

<pdcawley> Put it this way, how overengineered do you think something has to be before the XML folks start to notice?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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

      --

      -- Robin Berjon [berjon.com]