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

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 calling it "published".) At the heart, XML is nothing more than a serial text stream with angle brackets. Yet that text stream scales up to handle complex tree structures; with that property, it can be used for virtually every kind of information you need to exchange.

      The more important question to be asking is, is this the right problem to solve?, or rather is this the right level to solve this problem?. That is, do we want one universal format that is (notoriously) difficult to author, difficult to extend (witness WXS, SOAP, XLink), and makes data exchange more difficult?

      What I think Piers is trying to point out is that XML-centric solutions get way abstract before they ever gain a hope of becoming approachable. And with a universalist mindset, every addition to the XML stack makes the whole thing more daunting, even though each specific addition is only meant to address a specific problem, not a universal one.