Become a fan of Slashdot on Facebook


Forgot your password?
Programming IT Technology

Why XML Doesn't Suck 416

Richard Eriksson writes "Recalling the earlier discussion on why XML sucks for programmers, Tim Bray clarifies his stance on his co-creation, XML, and gets back on his pulpit to declare that XML Doesn't Suck. He writes: 'Let's look at some of XML's chief virtues, then I'll address some of the XML-sucks arguments, in the same spirit that Sammy Sosa addresses a fastball.'"
This discussion has been archived. No new comments can be posted.

Why XML Doesn't Suck

Comments Filter:
  • by cant_get_a_good_nick ( 172131 ) on Friday March 28, 2003 @11:18AM (#5615489)
    in the same spirit that Sammy Sosa addresses a fastball

    You mean he strikes out swinging on three pitches while trying to jack the ball in the stands instead of trying to make contact?
  • by mustangdavis ( 583344 ) on Friday March 28, 2003 @11:22AM (#5615515) Homepage Journal
    .... because people will pay you out the ying-yang to convert their system to use XML ...

    ... enough said!

    Besides, it is a great buzz word!!!

    • Exactly that... XML is mostly just a buzzword, used by middle-managers in meetings... Tech wise, it's fairly useful I spose, though I do wonder how much of it's adoption is out of usefulness and how much is from buzzword-manager-hype. At the end of the day, it's just tags -- though I'm being told they said that about HTML in it's day.
      • nuts! (Score:2, Insightful)

        I'm running OS X, and it sure sucks that almost all my preferences are stored in easy-to-parse buzzwords!

        XML is very useful. It's not XML's fault that Microsoft isn't implementing it.
        • I'm running OS X as well...

          XML is technically very useful, it's easily parsed, but it's an awfully hyped technology.
        • Re:nuts! (Score:3, Informative)

          by Anonymous Coward
          It's not XML's fault that Microsoft isn't implementing it.
          What on Earth are you talking about? .NET includes a fully-conformant XML parser. How else do you think you can write SOAP web services in .NET?
        • Re:nuts! (Score:5, Informative)

          by CynicTheHedgehog ( 261139 ) on Friday March 28, 2003 @12:50PM (#5616320) Homepage
          It's not XML's fault that Microsoft isn't implementing it.

          Are you smoking crack? I hate Microsoft as much as the next guy, but have you seen .NET? Holy cow. Everything having to do with data sets has been XML-ized, from query results to transactions to can't swing a dead cat without writing a schema first. Look at SQL Server 2000...everything can be done in XML. And then ASP.NET is XML-based (using the convention), and lets not forget the .NET app web.config file, which is XML.

          Granted, MS hasn't backported everything to XML (think we'll ever see an XML registry?) but everything going forward has XML tattooed all over it. I happen to love XML, but if anything Microsoft tends toward the zealous side.
        • Re:nuts! (Score:5, Informative)

          by Kombat ( 93720 ) <> on Friday March 28, 2003 @12:54PM (#5616358) Homepage
          XML is very useful. It's not XML's fault that Microsoft isn't implementing it.

          Ppppppht! *sprays water all over monitor* Microsoft's not "implementing it?" What in the heck do you mean by that? Have you taken a look at anything in the .NET suite lately? The entire system is built on XML. The solution files, project files, assembly manifests, application configuration files, setup binding files - they're all XML! Visual Studio .NET is build extensively on XML, and the .NET API includes some very intuitive and powerful classes for reading, manipulating, and building XML documents. I suggest you do at least a cursory investigation before spouting something so outrageously inaccurate next time.

      • I don't like to admit I'm using XML for just that reason. I generally get one of three reactions:

        1) "XM... did you just say HTML?"

        2) Are you using the .NET parser? Why not?

        3) *left hook*
      • by bwt ( 68845 ) on Friday March 28, 2003 @12:31PM (#5616172) Homepage
        XML is mostly just a buzzword, used by middle-managers in meetings

        Perhaps, but those meetings are about the fact that the department over there uses technology X and the department over here uses technology Y and the company saves $$$ if the two departments can actually talk because right now you pay people to do data entry twice and you pay more senior people to deal with the discrepancies.

        These managers ask their tech people "How do we deal with this problem" and they hear "XML" and take that up the chain.

        The bottom line is that in a company, system integration costs are the biggest expense in IT. XML decouples data from platforms and that makes integration easier and saves big bucks. So it becomes a buzzword because upper management needs buzzwords to describe things that enable.
    • Conversion... (Score:4, Interesting)

      by ackthpt ( 218170 ) on Friday March 28, 2003 @01:41PM (#5616811) Homepage Journal
      Um. Ok, I actually read the whole article and it has influenced my to change the direction, or consider strongly doing so, exporting data for archival purposes. We have an old system which will go out the door in the near future and I have been charged with archiving tables from a database in some form which makes they easily readable for auditing purposes, or for the more masochistic, able to be plugged into their happy little desktop database of choice (usually Access.) That said.

      That said, the challenge stems from MV-fields. Those nifty things in PICK which give you the power of keeping associated fields within one table, with as many associations as you like. (for good or for bad, bad usually when it's been abused or good housekeeping neglected.) Piling MV stuff into CSV is just plain icky. Normalizing it first is also icky. However XML may offer a simple, elegant way of keeping it all together in the shape it existed in (which may be important down the road if someone has to produce a report from it (auditors, second guessers, or a55-covering because some account didn't have the right amount of debits or credits for years and the difference needs to be found.)

      I'm off to explore XML more fully. There's probably yet-another O'Reilly book in my future...

  • Hang on... (Score:5, Funny)

    by Quixote ( 154172 ) on Friday March 28, 2003 @11:23AM (#5615526) Homepage Journal
    Going from "XML sucks" to "XML doesn't suck" isn't clarifying your stance! It is doing a 360. Even Bill "I didn't have sex with that woman" Clinton would have a tough time with this one.
    • Re:Hang on... (Score:5, Informative)

      by Anonymous Coward on Friday March 28, 2003 @11:28AM (#5615566)
      Actually its doing a 180.
    • Re:Hang on... (Score:5, Informative)

      by cant_get_a_good_nick ( 172131 ) on Friday March 28, 2003 @11:30AM (#5615586)
      It is doing a 360

      Going around in circles yet ending up where you started? I think you mean 180.

      We're going to turn this team around 360 degrees.
      - Jason Kidd, upon his drafting to the Dallas Mavericks

      That sounds like the Mavs., going around in circles but never really going anywhere.
      - Me.

      Well, then anyway, they're not all that bad at the moment, best motion offense in the league.
    • Re:Hang on... (Score:5, Insightful)

      by saddino ( 183491 ) on Friday March 28, 2003 @11:30AM (#5615587)
      That would be "I didn't have sexual relations with that woman" A subtle distinction. ;-)

      And to stay on topic, XML sucks for some things and doesn't suck for others, just like any other technology. A hammer claw is a fine tool for removing a nail, but not as useful for removing a splinter from your finger. Less energy needs to be spent on arguing whether technologies like XML suck or not, and more energy needs to be put into studying their most practical and optimal uses.
    • by HorrorIsland ( 620928 ) on Friday March 28, 2003 @11:34AM (#5615630)
      Even Bill "I didn't have sex with that woman" Clinton would have a tough time with this one.

      "That depends on what the definition of 'sucks' is..."

      No, I can see him saying that.

    • by mirko ( 198274 )
      Well, the question is no more about whether XML sucks or doesn't : the question is whether "that woman" sucked or not :)
    • Going from "XML sucks" to "XML doesn't suck" isn't clarifying your stance! It is doing a 360

      This reminds me of the Dilbert strip where Dogbert gives Ratbert a book titled something like:

      "Conversational Geometry for Idiots"

    • No. There is no contradiction between "Current XML parsing solutions suck for programmers." to "XML is a good thing overall." It's not a 360 [sic], because those are two seperate dimensions entirely.


      (One could argue that no good parsing solution is itself a weakness of XML, but IMHO the problem is that we got stuck going down the wrong road(s) for parsing, with SAX and DOM, both of which look good on paper but lack a certain practicality. If in five years there's still no good solution then maybe it
  • Apple Uses XML (Score:2, Informative)

    by Anonymous Coward
    It seems to work well for Apple. It works great for the core database for iTunes, iPhoto and many other apps :-)

    Steve likes it, he really likes it!
  • I DO hate XML (Score:5, Interesting)

    by ruiner13 ( 527499 ) on Friday March 28, 2003 @11:27AM (#5615560) Homepage
    I have to write SOAP calls for our .NET website, and i'll be damned if XML isn't the most irritating language ever. It wouldn't be so bad if everyone could agree on syntax, but since XML is so vague of a language for every implementation there is a different syntax, even amongst the SOAP standard XML specs. I am currently working on hafing our website make a SOAP call to a PERL::Lite SOAP server, and can't get the .NET to get the right data out of the response, even though the Perl server understands the .NET request fine, and is sending the right response. If it was really the panacea for programmers, there would be no interoperability problems. Sure, a human can look at any XML schema and know what is going on, but computers are the ones who have to deal with it, and they seem to have problems frequently.

    Just my 2 cents.

    • Sounds to me like your problem is your .NET tool set not XML.
      • Or SOAP on PERL::Lite.
        Cuts both ways.
    • sorry for the tools you're stuck working with, but xml as a language/specification is agreed upon. it's in the vendor's implementations where YMMV. i haven't worked with perl/soap, but many people find the xerces parser to work nicely.

      computers don't have to deal with the xml schema, it's someone's implementation of how to handle schema's is where the problem comes in.

      just my quarter.
    • SOAP itself is what you're really complaining about being inconstant between your Perl SOAP and .NET - if the documents parse, then XML is working fine.

      I don't like SOAP for most uses as it's overly complex for things like simple RPC style calls. Simple XML over HTTP can work just fine for how most people use the thing - it's not like everyone is doing distributed transactions or things that really take advantage of the SOAP envelope.
    • If you're using the proper tools, and programming with the proper libraries, there's no reason you have to dig down into the XML in order to "write SOAP calls". I've used SOAP for a handful of tasks, and I can't tell you anything significant about how the requests are represented in XML. Developers don't necessarily need to know that. If things are breaking for you, and you're having to debug the actual XML data to figure out what's going wrong, then either your toolset is buggy or you're not using it co
    • Re:I DO hate XML (Score:3, Informative)

      by kalidasa ( 577403 )

      XML isn't a language. It is a metalanguage. It is vague by design, to allow arbitrary languages to be created.

      XML is not a programming panacea. It is for structured data.

      Suck it up.

  • by BillGodfrey ( 127667 ) on Friday March 28, 2003 @11:28AM (#5615562) Homepage
    • by Randolpho ( 628485 ) on Friday March 28, 2003 @11:34AM (#5615629) Homepage Journal
      The wild popularity of XML as a basis for application-level protocols such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple Object Access Protocol [SOAP], and Jabber [JABBER] prompted investigation into the possibility of extending the use of XML in the protocol stack. Using XML at both the transport and network layer in addition to the application layer would provide for an amazing amount of power and flexibility while removing dependencies on proprietary and hard-to-understand binary protocols. This protocol unification would also allow applications to use a single XML parser for all aspects of their operation, eliminating developer time spent figuring out the intricacies of each new protocol, and moving the hard work of parsing to the XML toolset. The use of XML also mitigates concerns over "network vs. host" byte ordering which is at the root of many network application bugs.
      This is an example of what XML is *not* good for.
  • by Randolpho ( 628485 ) on Friday March 28, 2003 @11:29AM (#5615574) Homepage Journal
    XML sucks. XML doesn't suck.

    You're both right.

    XML is great for certain things, chief among them being human-readable / manipulatable data storage.

    XML sucks because of certain things, chief among them being complexity / verbosity.

    I think it's safe to say that XML is a niche -- not universal -- language. If we all accept that it's fine for certain things, but not for others, then we can all get along and go back to ripping Microsoft to shreds. :)
    • Exactly right.

      The problem is that most people like to live in a black and white world where some things suxors and some things rule -- whether it's for data formatting protocols or for politics.

      The larger my life experiences database grows, the more I realize that being overly accepting of things that rule or overly dismissive of things that suxors is normally a mistake. Actually using my brain to analyze things and see how they may or may not apply in any given situation is more mentally taxing, but p
    • by dvdeug ( 5033 ) <> on Friday March 28, 2003 @12:02PM (#5615869)
      I think it's safe to say that XML is a niche -- not universal -- language.

      Of course it's not a universal language; nothing is. But just because it's not the right tool for storing executables, doesn't make it a niche language, anymore then Perl or C are niche languages. Its "niche" is storing data in a computer-parsable, yet human-readable, extendable format. That's a lot of stuff.
    • by nehril ( 115874 ) on Friday March 28, 2003 @12:12PM (#5615980)
      after doing some "toy" programming with xml, I can definitely see both sides.

      XML Doesn't Suck:
      while working on a new java servlet app my text editor (Jedit) noticed I was working on an xml file (web.xml). it auto-downloaded the DTD, and the was able to gently remind me of missing or misplaced elements. This was so useful that I created a DTD for my home-rolled xml files, and Jedit was able to soft-validate and autocomplete those too. Not because Jedit understood what I was doing, but because it understands xml. Wicked cool, and "for free."

      XML Sucks:
      well, then I tried to read a simple XML config file into my java app using Apache Digester (candy-coated SAX parser). for a while I scratched my head wondering "why the hell do I need a stack and callbacks to read simple data?" attributes are fetched differently from tag contents. it is extremely non-intuitive. Eventually after poring over enough examples I "got it," but the process is so far divorced from what I actually want to do that I almost didn't get there.

      anyway, at least now I have a more balanced view than "xml r0x" or "xml suxx0rs." what's needed is an XML api that is fast and makes immediate sense.
    • IMHO, XML was not designed to be human readible. While early XML examples were readible (for simplicity's sake), anyone trying to read a SOAP envelope or gasp! an XQuery query will be quickly dismissed of the human readibility. RosettaNet and some of the financial XML I've used I would never touch without an XML editor.

      XML was designed to be universally machine readible. In this sense, rather than depending on byte codes, positional values, INT/WORD/DWORD etc. etc. differences (not to mention time and d
  • by Anonymous Coward on Friday March 28, 2003 @11:29AM (#5615578)
    Recently in this space I complained that XML is too hard for programmers. That article got Slashdotted and was subsequently read by over thirty thousand people; I got a lot of feedback, quite a bit of it intelligent and thought-provoking. This note will argue that XML doesn't suck, and discuss some of the issues around the difficulties encountered by programmers.

    XML Doesn't Suck This is going to be fun. XML first saw the light of day in November 1996 and between then and 1999 or so I spent most of my time trying to convince people that XML was a good idea and they should use it. In recent years, though, my XML-related work has been much less, due to my role at Antarctica, and has been focused on corner cases and weird interactions, due to my participation in the W3C TAG. So it's going to be a refreshing change to get on the old familiar pulpit and preach the XML gospel a bit.

    I'm doing this because quite a few people reacted to my article by saying "See, a co-inventor of XML admits that it sucks, like I've been saying all along." (Many of them obviously hadn't read the article, but anyhow). Some of the XML-sucks arguments were:

    It's verbose
    XML does a lousy job of what Lisp S-expressions could do decades ago.
    XML does a lousy job of what comma-delimited files could do decades ago.
    XML has a stupid design with two completely different mechanisms for holding content (elements and attributes), and then there's that weird "mixed content" thing.
    XML can't make up its mind whether it wants to be a tree or a sequence.
    XML is nice and straightforward but to use it you have to learn all this seriously ugly and complex stuff like XPath and XML Schema.
    Bah. Sticks and stones, etc. Let's look at some of XML's chief virtues, then I'll address some of the XML-sucks arguments, in the same spirit that Sammy Sosa addresses a fastball.

    XML Has Internationalization Pretty Well Nailed Sometime in the last few years, native speakers of English became a minority of Net users, and I'm quite certain they're a minority among users of computers in general. Up until the late nineties, I suspect that the vast majority of application writers basically didn't understand i18n issues, didn't care, and many didn't think they needed to (i18n is an abbreviation for "internationalization"). Those that did often thought they could get away with hacks like switching Microsoft Code Pages or using the much-loathed ISO 2022.

    XML, I think, gets a lot of the credit for changing that. In XML, there's no ambiguity - a document is a sequence of characters, and characters are numbers, and the numbers mean what Unicode/ISO10646 says they mean. There are lots of different ways to store those numbers as bytes in data files, but XML forces you to say which one you're using right up front. Larry Wall said it best: "An XML document knows what encoding it's in."

    Basically, XML doesn't let you get away with ignoring the issues. While there is some ongoing tinkering with XML's i18n facilities, that's mostly because Unicode/10646 itself has been changing.

    If I had to pick the biggest contribution XML has made to the world, this would be it - forcing people to learn the issues and start doing the right thing.

    XML Can Represent Pretty Well Anything I don't need to expand on this very much except to note that XML has been used to represent, without loss of information, algebra, bibles, computer programs, database records, email, filings to regulators, GIS data, human-resource data, iTunes collections, journal entries, KR data, logic, manuals, network maps, ontologies, purchase orders, queries against databases, remote procedure calls, schemas, transactions against commerce servers, update logs, vector graphics, winecellar inventories, XXX movie metadata, yearly calendars, and Zen koans. OK, I don't know for sure about the koans.

    That's a lot of syntaxes that didn't have to be invented.

    XML Forces Syntax-Level Interoperability "Interoperability" has been a mantra since I've been in t
  • One word: Marketing

    I have no doubt that most people would agree that there are just-as-easy-to-understand standards out there, and for certain tasks, some are much better. The advantages that XML has are that it'll expand to fit most any application (which is matched), and most everyone already knows how to use it, through knowing how to use HTML, if nothing else (which isn't really matched).

    The reason most everyone knows how to use it is that, at one point, the right people jumped on the XML marketing

  • by Spudnuts ( 21990 ) on Friday March 28, 2003 @11:31AM (#5615599)
    Mr. Bray makes a point about the longevity of XML based documents (where he says that tying up documents in a binary format is foolish), but this is a point that (La)TeX users have been arguing for years.

    Will XML really solve this problem? Hopefully the OpenOffice format will help, but if Microsoft maintains its marketshare (and keeps its XML generation limited or even proprietary), are we really better off?

    I'll just stick with LaTeX.
  • by xagon7 ( 530399 ) on Friday March 28, 2003 @11:32AM (#5615606)
    I havn't read the article yet, but XML does NOT suck because:

    1. the data and/or fields added at anytime WITHOUT breaking anything

    2. the data is in a heiracherical format, reducing data replication and allowing for a more sophisticated data structure.

    3. the daya can be changed by a text editor.

    4. and BECAUSE the data is text, it compresses REALLY well.
    • by jandrese ( 485 ) <> on Friday March 28, 2003 @11:43AM (#5615707) Homepage Journal
      4 is a big old red herring.

      The data compresses so well because it's encoded in a highly inefficent manner. Your average compression algorithm will be able to find more redundancy and give you a better % compressed, but it still won't compare with a human actually packing the data tightly together in the first place.

      or, to take a more information theory POV, there is a certain amount of information in your post, which can be compressed down X percent by default. That same information has to be encoded in the XML version, and has the additional overhead of XML to deal with, so even compresed it will always be larger than the compacted and compresed binary only version.

      XML has a lot of strengths, but compactness is not one of them.
      • The data compresses so well because it's encoded in a highly inefficent manner. Your average compression algorithm will be able to find more redundancy and give you a better % compressed, but it still won't compare with a human actually packing the data tightly together in the first place.

        I strongly suggest you take a complex MS Word document, and convert it into StarOffice 5.0 format, then into OpenOffice 1.0 (XML) format. The filesize of the OpenOffice 1.0 (XML) document will be FAR smaller than either

    • Re: your point #4 take this simple table with two columns:

      day sales
      1 32
      2 23
      3 22

      And let's write it in xml

      <sales >

      I think you can see the redundancy here. Both are text, no matter how you compress it the second will be larger
  • What's the big deal? (Score:5, Interesting)

    by Telex4 ( 265980 ) on Friday March 28, 2003 @11:34AM (#5615622) Homepage
    I don't get all this fuss over XML. It seems to me that it's just a pretty handy markup language for programmers to use to store data in a human-readable (and therefore human-editable) fashion, that (with the help of things like libxml) also happens to be fairly machine readable. It's also extensible (X- duh!) and yet also has its limits.

    Why are there so many /. stories about this? Can somebody explain why this raises people's passions so? It seems to me like arguing the merits of HTML or SGML - it's all so bloody obvious!
    • by Anonymous Coward
      If I have a system and I want to publish some data so that you can read it, we used to have to go through a long song-and-dance routine where we decided what byte-order things were in, and which character sets we were using, and exactly to the bit how various fields were aligned. Once we'd hammered out a 40-page design spec of our interop format, you'd go and code a reader to the spec and I'd go and code a writer. Then we'd come back and find we still couldn't talk to each other because of inconsistencies a
    • by DeadSea ( 69598 )
      I felt this way when I first looked at XML. I said, "Boy, XML isn't that exciting. Its a way of formatting data. Its human readable. Whoop-dee-doo."

      The power of XML comes not out of its syntax but out of the tools that are there for it and what you can do with them.

      The nice (if obvious) tool for XML is the parser. XML is specified so that any computer science undergrad could write one in a couple weeks. As a result, there are a lot of parsers out there and they all do the same thing. This makes

  • by dsoltesz ( 563978 ) <> on Friday March 28, 2003 @11:34AM (#5615623) Homepage Journal
    As a web developer & admin, XML is my best friend. I have cases where I need non-webheads to develop content (better yet, portable content), and XML is the only way - they only have to know a basic set of HTML tags, they don't have to worry about HTML validation, formatting, or anything else, and everything they generate is consistent!

    Not ony can I transform their content into different views or formats, but (for example) the same XML file that is used to provide software documentation also is used to build the software GUI and provide tool tips and other forms of context sensitive help.

    No database required. No parsing required. Just a couple libraries and tools, and we're set to go.
    • I don't know XML. I used to know HTML. It used to be simple and consistent and easy to manage, too. But I don't know it anymore because it's expanded into this monstrosity that requires validation, formating, and whatnot.

      How long will it be before XML, which may be simple and easy to make consistent now, is "extended" into a similar monster, only to be replaced by some other "savior" specification?

      Why is it so difficult for us to recognize that, except for the most basic of things, automation is hard.
      • HTML has always had a recommendation, and always required validation - I have found old files harking back to HTML 1 that would not be valid. Monstrosity? You must be referring to all those cool new features we've been begging for to make our HTML robust and accessible, not the least of which is CSS, which allows me centralize the formatting schemes into one file instead of having to global replaces on 500 (and hope I didn't screw it up).

        Automation is hard? I write a little stylesheet, similar to writing a
  • send it vith SOAP.
  • by MyTwoCentsWorth ( 593731 ) on Friday March 28, 2003 @11:35AM (#5615635)
    XML is much better that anything else in certain situations.

    XML is much worst that lots of other choices in certain situations.

    Why can't you see the shades of grey, and insist on seeing all in black and white ?

    Have fun,

  • Code embedded in XML (Score:5, Interesting)

    by CyberGarp ( 242942 ) <<Shawn> <at> <>> on Friday March 28, 2003 @11:35AM (#5615637) Homepage

    I saw a letter to Dr. Dobbs recently that was saying that XML needed to have the ability to embed things like Visual Basic and javascript in it to be really useful. I think that this is a horrible idea. The whole point of XML was to have a generic data model, i.e. one parser to rule them all.

    I've been able to do thing like export MySQL schemas into XML, then using XSLT generate an entire set of base classes providing persistent objects. What was once weeks worth of work, now takes an afternoon (from concept to final product). The whole set is entirely consistent, no misspelled names or changed signatures. When bugs were found, I fixed all the files in one place and rerun the XML/XSLT script. Massive productivity boost. If that isn't an argument on why XML doesn't suck I don't know what is.

    The idea of embedding code in XML is a perverse distortion of what XML is really about. XML would suck if one uses it for unintended purposes. I don't use a hammer to tighten machine bolts, well I guess some people do.

  • by Anonymous Coward
    <include file="stdio.xml" />
    <function name="main">
    <if:xml sucks="true">
    <printf>XML sucks as a programming language</printf>
    <printf>XML rules as a programming language</printf>
  • I want something that works like the Database Template Library [] for XML. It'd be nice just to map XML tags into a structure and suck the whole XML file in using an iterator.
  • by Carnage4Life ( 106069 ) on Friday March 28, 2003 @11:37AM (#5615654) Homepage Journal
    The main thesis of Tim Bray's original post was that he didn't like having to choose between either storing all his data in memory (i.e. DOM) or using a callbacks(i.e. SAX) when processing XML. The problem with this kind of thinking is that although it may have been true two or three years ago that the only way to process XML was via DOM or SAX this is no longer the case.

    There are more classes of APIs supported on multiple platforms for processing XML such as pull-based APIs and cursor based APIs which are represented by the System.Xml.XmlReader [] and System.Xml.XPath.XPathNavigator [] in the .NET Framework. Similar APIs exist in the Java world as well as Python from what I've heard. This is besides the current push in some [] quarters [] for programming languages that natively process XML (i.e. intrinsicly understand an XML datamodel or datatype).

    Tim Bray's original problem was that he doesn't have a pull-based API for XML parsing in Perl. I pointed out in my kuro5hin diary [] how the pseudo code he showed as being his ideal for processing XML already exists in C# and .NET Framework. This article on [] points to other people who also point out that such pull-based APIs for processing XML are available on other platforms and languages as well.
  • by B3ryllium ( 571199 ) on Friday March 28, 2003 @11:39AM (#5615676) Homepage
    this [].

    Some of you may already have read it, but it's on-topic nonetheless. :)
  • A bit off topic... (Score:3, Interesting)

    by ed1park ( 100777 ) <ed1park@hot[ ] ['mai' in gap]> on Friday March 28, 2003 @11:43AM (#5615703)
    poking around his site I came across this. hehe.

    "Slashdot and Stupidity I visit Slashdot once per day, sometimes more, because they seem to do a really good job of relaying the geek zeitgeist. It's a long time since I read much of the follow-ups, but I thought I ought to this time, and I'm reminded why. How can a publication that caters (on the face of it) to smart people attract the attention of so many shallow, drivelling morons?"

    "Interactivity Again There were a few smart things there in among the chaff on /., and by following back the links in from other blogs, I sure did learn a whole bunch about the state of the programming art as regards XML. Some of the things I said were wrong (or at least open to challenge), and I got fodder for a really substantial follow-up piece, which I'll get around to soon. I don't suppose it's mathematically possible for everyone to get their theses batted around by some tens of thousands of well-informed people, which is a real pity." 9/ Who
  • XML is just XML (Score:2, Informative)

    by DeepDarkSky ( 111382 )
    There are shortcomings to XML, certainly. Having worked with it, I know that I've had someissues. But the benefits that it brings (the human readability, the structure, and the parsers that are available for it, etc.), makes it a good thing much more so than a bad thing.

    Programming for XML is more work, but in the end, it forces you to be more structured and disciplined to work with it. You are always working with standard way of constructing data and messages, rather than having to reinvent a new wheel
  • by Ars-Fartsica ( 166957 ) on Friday March 28, 2003 @11:47AM (#5615733)
    The W3 just can't leave a good standard alone. They keep heaping crap upon the good name of XML (e.g. XML Schema) too far ahead of industry demand. Now they are going to end up assenting to multiple DTD alternatives when they start talking about RELAX/TREX etc. What they should have done was waited for industry to determine the best approach (RELAX, not Schemas), and THEN standardize.

    They can't help it though, the W3 committees are infested by the same lifers who destroyed SGML. It would be refreshing to see a standards committee for once run by people who are suspicious of standards committees. Right now the XML world is run by the people who live off of the small cred being on a committee lends to their consulting biz, etc. so they have no motivation to ever finish the committee's works.

  • XML is acceptible for eyebaling data but when you take into effect how verbose it is, it becomes very wasteful for transmitting over small pipes (modems)

    A simple look up table and RLEing the results with a checksum can offer significant savings.

    For an exercise, try sending a 900 K XML file off to a server and wait till it's done. Then look at the XML and see how you could make it smaller. It's kinda obvious and sad that it wasn't done in the first place.
  • XML as dough (Score:4, Insightful)

    by WetCat ( 558132 ) on Friday March 28, 2003 @12:00PM (#5615853)
    People who say XML sucks are the people who are forced to look at it and change it by hand.
    But XML is not for that!
    XML is like dough. Nobody eats raw dough (it's probably OK to eat it, but it ISN'T tasty), but eats cookies and bread instead.

    XML is NOT for user and/or administrator usual exposure, XML is for application data transfer.
    And applications that require XML to be written by human are only half done: they should be used in combination with HumanInput -> XML generation programs.
  • Why do I like XML?
    1. Reverse engineering a file parser is much easier . If my current document were some reasonable XML file I would not be spending the hours staring at hex code trying to delimit variable formatted recored.
    2. I'm a little lazy, and tired after doing 1 above and I don't want to write my own parsers.
  • by jeti ( 105266 ) on Friday March 28, 2003 @12:01PM (#5615868) Homepage
    No. Really.

    There are IEEE specifications for numbers that are exact down to the bit. And processors actually comply to them.

    Now convert your number to text, using a decimal representation (as AFAIK is recommended for XML). What you get is typically not the number you had before.
    • by Simon ( 815 )
      Then don't bloody store your number in a decimal representation. If your application requires numbers in a certain IEEE spec format, them output them using base64, or C style 0xaaff1234 format or something. Or you could even do both. Output as decimal and then output a matching [ieee_fp][/ieee_fp] tag or something. XML is extensible that way. There are so many things you could do.

      A recommendation is just that, a recommendation. If you have more important goals then do something more appropriate. XML doesn'
  • It's just a layer (Score:2, Insightful)

    by scrotch ( 605605 )
    Seems to me that Plain Text is a pretty good document type. Seems that XML is a way of structuring some of that data. Seems that something else has to be layered over that - specifically, the tags that you create.

    So when you read the file, you parse the text, then the XML, then your tags to get your data into a usable state. XML is is just a way of formatting text. That's where the "meta" comes in. It's not a document type, it's just a standard for creating document types.

    The only way XML makes data long
  • by binaryDigit ( 557647 ) on Friday March 28, 2003 @12:15PM (#5616013)
    You read some of the arguments against XML, and you realize that people just don't "get it".

    1 - XML sucks as a language

    Repeat after me, XML is NOT a language. Certainly not in the sense that C++ is a language. XML is a standard that defines how one structures data.

    2 - XML is bloated, I can send binary much cheaper/easier

    DUH. If your application is fine using binary data transfer, then USE it. HOWEVER, many applications that either have to A) communicate with other applications or B) have to deal with varying data sets benefit greatly from using XML. Anyone who has been programming for any length of time knows that while binary is more compact, it is less flexible and potentially more error prone. Want to add a new field in the middle of your data, boy you better not get your software versions mixed. Want to write an app that can do reasonably intelligent things with ANY data it recieves, binary is not the way to go. As with all things in life, use the tool for that which it was intended (vs some peoples view that it is the end all be all of data representation).

    3 - It's slow

    Same as 2 above. If absolute performance is an issue, then by all means, use whatever representation gives you what you need. XML is about flexibility and standardization, NOT performance.

    4 - It's complex

    Well as complex as you want to make it, and it does sometimes encourages more complexity than is really needed, but it doesn't FORCE you into it. If you want/need schemas, go for it. If you need the functionality but in a simpler form, then do that (unless of course you need to communicate with another system expecting a schema, but his is obvious). It's just like C++, you don't HAVE to use templates and multiple inheritence (hell, you don't even have to create classes if you don't want/need), you use the parts of the tool that are useful and provide benefit, you don't use them just because they're there.

    So I don't see what all the bruhaha is about. It has it's strengths, it has it's weaknesses. As with anything, relatively, new, people are trying it in various places. Some of these places not really fit, others do. I've designed apps that benefited greatly, others I've dismissed xml for entirely.
    • How is "XML" pronounced?
    • Just the letters "X" "M" "L" ?
    • "Zee mul" ?
    • "Smell" ?
    • "A standard until it was compromised by Microsoft" ?

    How do I encode properties (fields) of my data: child elements or element attributes?

    How do I join the preceding-sibling namespace descendent ancestor-or-self following axis of evil?

  • by Anonymous Coward on Friday March 28, 2003 @12:17PM (#5616032)
    I work for a VAN (Value Added Network) which is basically a middleman for data. You send an electronic purchase order to us; the company you're ordering from gets it from us. The value we add is we'll say you sent and tell you they got it.

    However, we charge by the kilocharacter of data you send and receive per month. So, for us, XML is awesome, because it increases the size of an ASCII-X12 or EDIFACT document by a factor of 5-a lot more (usually somewhere around 15-20 I think).

    X12 and EDIFACT are standards for business document exchange that have been around for a while, but people are converting to XML because they think it's better (eventhough, usually, they just use the X12 or EDIFACT format, but with XML tags).

    For example, a line item record may go from something like this:


    to something like this:


    It's not always that bad, but it can also be much worse. (Imagine replacing each instance of "LIN" above with "Line_Item" and "LIN_01" with "Line_Item_Number".) (And why won't that semi-colon after the LIN_01 end tag go away?)

    so-- for us, XML doesn't suck-- it increases our revenue. For our clients, it's sucks, because it increases their monthly bill.
  • Yes, but... (Score:3, Insightful)

    by gillbates ( 106458 ) on Friday March 28, 2003 @12:22PM (#5616086) Homepage Journal
    The only way to achieve interoperability at the software interface level is for there to be exactly one implementation - for example Perl or Linux.

    Hate to burst your bubble, Tim, but this is the same justification that Microsoft to defend their monopoly on PC operating systems. There wouldn't be any portability issues if everyone used Windows(but there might be stability issues!)

    And I agree with the notion that standards are a good thing, however, I have to be realistic at the same time. Any standard sufficiently broad to cover all of the possible bases will be so general as to be useless, or at the least, very inefficient in a large number of cases. The reasons why different standards crop up is because different users have different needs and values. In the UNIX community, portability, stability, and interoperability are highly regarded, where as in the Windows community, flashy GUI's and speed are often more important. Hence, two widely different systems.

    The portability of XML is nice. The fact that it can represent just about anything is also nice. But the nature of XML precludes indexing, which means if I'm searching for a particular record in an XML dataset, I might have to read the entire file. Not a problem for small databases, but for mainframe size databases, this is simply unworkable.

    No, XML doesn't suck. But then again, it's not a silver bullet either. Need I say the adage about hammers and nails?

  • Just make </> close whatever the last tag was. That instantly cuts the size of the files in almost half, and makes them easier to read as well.

    And yes, it could be confusing in a heavily nested file, but nothing says you have to use them. It would be a godsend for database columns.

    • Just make close whatever the last tag was. That instantly cuts the size of the files in almost half, and makes them easier to read as well.

      Spot the 'lite' user of XML. If you're dealing with anything of any size, complexity or (let's face it) use, then that's a really good idea for unmaintable, buggy XML.

  • by plopez ( 54068 ) on Friday March 28, 2003 @12:36PM (#5616204) Journal
    It has been my observation that much of 'XML' work with the query engine extension has been a recreation of hierarchical databases. But relational databases were designed to overcome hierarchical databases' failures. It seems we are turning back the clock. For a good critique of XML, C. J. Date's site has an article critical of XML

  • XML is really nice (Score:3, Interesting)

    by amalcon ( 472105 ) on Friday March 28, 2003 @12:40PM (#5616232)
    Two words:

    As a programmer, this is the most useful property a data stream can take on. Why? Debugging. The reasoning here is twofold:

    1. Non-parallel development of opposite ends of the data stream:
    It's quite a challenge to develop the code which produces the data and the code which uses the data at the same time. If it doesn't work, you don't know where the problem is. With a human-readable format, you can simply pipe the data in or out of the app directly from a text file, and verify that it's correct yourself.

    2. Debugging:
    Something of an extention of the previous, if you have two bits of code communicating through XML, you can log the bad transmission and read it yourself to find out if the bug is in transmission or reception.

    Now, I won't pretend that XML is the only human-readable data-structuring format, but it has a lot of nice advantages over the others, each of which is covered in the article. XML makes apps a pain to develop, but a breeze to debug--and the debugging is far more important!
  • Solve this Problem (Score:3, Interesting)

    by Enonu ( 129798 ) on Friday March 28, 2003 @12:40PM (#5616234)
    Let's say you are using XML to store the class rosters for your school. Assume the structure, <class><student>. This has the advantages of being the easiest to parse, you create your data-structure and it's finished, and lastly, writing XSLT to convert your XML to HTML is a piece of cake. However, it's both redundant in the XML itself and in memory.

    Assuming something more efficient, like <class><studentId>, where you simply reference students by an id rather than inlining each student's data, removes the reduplication problem. However, everything else becomes harder. First, you have to be able to reference a student by its id, so you use a hashtable. Next you either have to require that student data comes first, or you have an update phase where you update each of your class objects. Lastly, XSLT isn't cake anymore (show me the roster for class X including all the students details).

    Although this problem exists in any other application that parses data that contains internal references, it's still a major pain-in-the-ass.

    What's the best way to tackle this situation?
  • by Artful Codger ( 245847 ) on Friday March 28, 2003 @12:56PM (#5616373)
    ... Like most of folks here, we've successfully used it in several situations, across different languages (Java, Perl, ASP) and different purposes(configuration, data transfer, web page generation, small online data storage, etc). It's da bomb.

    XSL/XSLT on the other hand can be a pain to use in anything other than trivial transforms, in my unschooled opinion. The concept of recursive processing is great, but the math/logic syntax available is byzantine (eg "variable" is really a constant).

    *sigh* I know this will get modded offtopic, but seriously... anyone agree with me, or do you actually like writing transform logic and processing in XSL? Please comment.
  • by ites ( 600337 ) on Friday March 28, 2003 @12:57PM (#5616391) Journal
    In the last five years, XML has - for instance - completely revolutionized the way my company writes software. We use code generators that mungle XML definitions into templates (imagine PHP controlling the generation not of HTML but of C or... PHP, and using XML to specify the abstract model in question).
    We don't need schemas, stylesheets, xpaths,... just simple XML. And yet we can write very rich code in XML instead of in native code. Today we're producing about 25 lines of final code for 1 line of XML, and we're pushing this up all the time. My current project generates workflow engines from XML definitions, building a 10k workflow application from a single 500-line XML file.
    My point is that XML is not just a handy way to store data. It is a meta language, able to formally define any concept, no matter how abstract. This is an incredible but subtle thing. The power comes not from XML technology itself, which is really very, very simple once you ignore the W3C fluff. The power comes from the freedom that XML technology gives you, namely the ability to abstract your problem to as high a level as your mind can take it, and to solve it at that level.
    This is difficult, and takes time, but as the XML space settles down it will become clear that this is the real value of the technology.
    The 'con' arguments all appear to be related to people trying to use XML in the wrong place, for the wrong thing, or to replace existing abstractions that work perfectly well.
  • by SuperKendall ( 25149 ) on Friday March 28, 2003 @01:03PM (#5616471)
    From article:
    "XML Can Represent Pretty Well Anything"
    "XML has been used to represent, without loss of information...yearly calendars, and Zen koans. OK, I don't know for sure about the koans."

    <koan attribute_to="Chao-chou">
    <question asked_by="random monk">
    Does a dog have Buddha-nature or not?
    <response master="true" smileQuizzically="true" useMuResponse="true"/>
  • by danmil ( 11416 ) <> on Friday March 28, 2003 @01:19PM (#5616624) Journal
    Most of his (excellent) points have to do with exchanging data between applications (with long-term storage being essentially a special case of that). And he's right -- for those, XML is a huge win, and we should all bow down and worship at its feet.

    However, because XML is such a huge buzzword now, people are proposing (or insisting on) using it as a format at the heart of complicated applications. Where anyone would have said 'Use a database' a few years ago.

    In doing so, people are losing sight of the essential beauty of the relational data model. With a RDBM, you, the programmer, have tremendous flexibility about *how* you view your data. This is a huge win inside of an application. XML forces you to commit to one specific view of your data. Yes, if that data needs to live forever and yes, if that data needs to get sent to someone else, than by all means, store it in an XML file. But if you need to *do* something with that data, you're going to be much happier with a relational db.

    • XML forces you to commit to one specific view of your data.

      This is why XML serves best as an interchange format, where files are immutable snapshots of more complex data sets. Perfect for EDI-type apps or reports, but not for "live" data.

      I know from experience with MCAD files (Pro/E, etc.) that static snapshot-type files are much easier to generate and work with than "live" files (files that are modified, stored, modified again, stored, ad nauseum). This is because data that changes over time has to st
  • by Bedrock ( 660829 ) on Friday March 28, 2003 @01:36PM (#5616768)

    I work for a publishing services firm that is focusing on XML-based production of print and online materials, ranging from books to scientific journals to grade-school testing applications.

    Simply put, XML is the best tool available for storing content to be databased, searched, rendered in multiple formats and broken apart and reconstituted into custom documents. XML also lends itself nicely to the representation of complex mathematics using MathML. Because of this, we've based many of our production processes on XML.

    One particular journal we produce is a heavily mathematical, 250 page weekly scientific journal. This journal is produced in both print and online forms, as well as being databased by the publisher. Using tools such as Arbortext Epic ( []) for content editing and Advent 3B2 ( []) for semi-unattended formatting we are able to produce the journal with a staff of only 10 people. A year ago, it took twice as many people and the end product was not nearly as flexible. In this application, XML rocks.

    However, using XML in every application imaginable without considering whether or not it's the appropriate tool can be quite foolish. A hammer is great for pounding on things, but is pretty worthless in nearly every other application. A lot of the frustration felt by coders implementing XML solutions is due to the fact that it may not be the best tool for the job.

  • by Eneff ( 96967 ) on Friday March 28, 2003 @01:46PM (#5616860)
    language definition []

    A language is the set of all ways a grammar allows symbols to be combined.

    (of course, a grammar is a set of rules on how to combine symbols.)

    Under the formal definition, XML is indeed a language. It is not a language useful for defining algorithms, admittedly.

    Can we stop with this "XML is not a language" now?

  • by ProtonMotiveForce ( 267027 ) on Friday March 28, 2003 @02:06PM (#5617108)
    Is it the best? Probably not. But it's undeniably an effective lingua franca. A human can easily creat, edit, and manage it dynamically - you want a new tage you just do it.

    Then, it's also as easy on the software side to reflect those changes. The fashionable arguments people use against it (why is it so fashionable to bash anything that happens to be a buzzword?) are non sequiturs in terms of what XML is intended for.

    I use it, hell I probably overuse it. It's so damn easy to parse that I don't want to waste time building a custom format just to save that extra 1K of space or 1/100th of a second.
  • XML Sucks (Score:3, Insightful)

    by magic ( 19621 ) on Friday March 28, 2003 @04:25PM (#5618334) Homepage
    His arguments appear to be based on an assumption: humans are going to hand-code XML and want wierd syntax because of that (e.g. attributes, explicit close tags, the ridiculous XPath grammar). I doubt that 1% of the world's XML (by character count) is hand written today, and think this assumption is a poor one to make.

    I could care less whether "<", "(", "{" or any other character begins a tag. The structure of

    '(a (href "") (text "CNN"))
    by a mile.

    Data should be stored in a way that is easy to parse and unambiguous to design. XML would have been better designed with a way to represent pointers (e.g. LET/LETREC) than the silly attributes and other syntactic nonsense.


  • by coats ( 1068 ) on Friday March 28, 2003 @04:45PM (#5618506) Homepage
    I'm an environmental modeler (think supercomputing) , and most of the time the stuff I generate won't fit into dinky little 2GB files. Model data doesn't compress well (and even if it did, it'd take too many tera-ops). And then, forcing it into a sequential access model is not a good idea.. When you have a 10GB data set, you really need direct access to mine the contents, rather than having to "eat the file whole."

    But bureaucrats being what they are (and bureaucrats being in charge of environmental agencies), they've been told that XML is a GOOD THING, and want to force everything into that mold. And it doesn't fit!

    Call it the "law of the instrument," as someone (Poul Anderson, I think, put it:

    As soon as you invent a new and better type of monkey wrench, you can be sure someone will make use of it -- as a bludgeon!
    That's XML, to a tee!

  • XML is great (Score:3, Interesting)

    by master_p ( 608214 ) on Friday March 28, 2003 @05:33PM (#5618900)
    Some people here say that XML is just a buzzword with no real advantages etc. Let me tell you, they are all wrong.

    My company makes apps for the military. These type of apps make heavy use of binary messages exchanged over a network. Up until now, there were numerous errors in the specification, different type systems and other problems between departments. With XML, we managed to do the following:

    1) make a standard for expressing messages. Since messages are tree structures (struct embedded in struct etc), XML is ideal for it.

    2) made a tool to write messages and group them according to context. Now specification docs can be automatically produced by the tool and handed over to subcontractors, whereas previously they were written by hand, contained many errors and had different styles. Now all these problems are gone, changes are documented and saved in the configuration and versioning/control system, messages are automatically versioned and the whole procedure is automated to the point that it takes a few clicks to modify a message and produce a new specification.

    3) made tools which can prepare scenarios for testing these messages automatically. This saved us a lot work!!! it is quite a big amount to test every field of every struct of each message from the up to 10000 message a combat system has (and each message can contain hundrends of numeric fields)!!! thanks to XML, each field's bit width, range, default value, minimum and maximum value and enumeration is known beforehand from the XML data produced for the specification, so by using XSLT messages are automatically converted to C, C++, ADA and Java code along with the relevant code to send, receive and validate each message.

    One of the true benefits of XML is that data are not tied to a specific application. For my company, it has saved us a lot of work, because there is no need to bloat one app with all the functionality, we can make several separate tools which do one job only and operate on those XML data.

Thus spake the master programmer: "Time for you to leave." -- Geoffrey James, "The Tao of Programming"