Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
The Internet

Tim Bray on the Birth of XML, 10 Years Later 260

lazyguyuk writes "Tim Bray posts a lengthy blog on the birth of XML, formalized as 1.0 in Feb 1998. 'XML is ten years old today. It feels like yesterday, or a lifetime. I wrote this that year (1998). It's really long. The title was originally Good Luck and Internet Plumbing but the filename was "XML-People" and I decided I liked that better. I never got around to publishing it, so why not now?'"
This discussion has been archived. No new comments can be posted.

Tim Bray on the Birth of XML, 10 Years Later

Comments Filter:
  • Classic (Score:5, Funny)

    by Gothmolly ( 148874 ) on Monday February 18, 2008 @12:45PM (#22464414)
    Young Buck: Hey, we have a data exchange problem between two systems, lets use XML !
    Greybeard: Ok, but now you have 2 problems.
    • Re:Classic (Score:5, Insightful)

      by smittyoneeach ( 243267 ) * on Monday February 18, 2008 @01:07PM (#22464668) Homepage Journal
      In defense of XML, the parsing problem is handled.
      Best wishes on solving the semantic snarls.
      XML, like all good approaches, handles mechanism, not policy.
      • Re:Classic (Score:4, Interesting)

        by fireboy1919 ( 257783 ) <rustypNO@SPAMfreeshell.org> on Monday February 18, 2008 @01:29PM (#22464930) Homepage Journal
        In defense of XML, the parsing problem is handled.

        To me that says that XML handles a problem that wasn't there. Parsing problem for pretty much everything is almost universally solved by regex...

        I don't really care about the XML format. Personally, I'd be happier if it were stored in binary. The thing I like is the DOM tree as a data construct, XPath as a means of addressing, and XQuery as a means of getting parts out of it. (XSLT is okay, but from my experience, it's a lot clearer to represent a transformation as a series of productions than it is to use XSLT...perhaps a production-oriented approach that used XPath addressing?)

        With those, you've got a good mechanism for serializing, reading, and deserializing objects, classes, and all manner of other things.

        There are only a few problems with this:
        1) Non-ancestor relationships and references (i.e., having the same node as multiple locations in the XML document) are not covered by XML, but are possible with objects.

        2) Attributes in XML have no obvious mapping to objects...so what do you do with them?

        I wish we could use something like XML (in that it could use DTDs as schemas, and had support for DOM methods along with XQuery and XPath), but with a more effecient format (binary), and with the ability to encode references.

        That would be just about perfect.
        • Re:Classic (Score:5, Insightful)

          by oyenstikker ( 536040 ) <slashdot AT sbyrne DOT org> on Monday February 18, 2008 @01:45PM (#22465136) Homepage Journal

          There are only a few problems with this:
          1) Non-ancestor relationships and references (i.e., having the same node as multiple locations in the XML document) are not covered by XML, but are possible with objects.
          You can with refids and keys.

          but with a more effecient format (binary)
          It is wonderful to be able to easily read and edit the data in a text editor. If you want it more compact for storage and transmission, compress it. I understand that a binary format could lead to more efficient processing and parsing, but I think the benefits of readable text outweigh the efficiency.
        • Re:Classic (Score:4, Insightful)

          by Flambergius ( 55153 ) on Monday February 18, 2008 @02:08PM (#22465398)
          To me that says that XML handles a problem that wasn't there. Parsing problem for pretty much everything is almost universally solved by regex...

          XML doesn't handle parsing. XML makes parsing easier; in fact so easy that parsing XML isn't a problem anymore.

          For an expert, I think XML and regex are complementary techniques. For anyone other than an expert regex are way too brittle. Ordinary people need to be able to operate on their data, it can't require voodoo. (Not that XML in all its arcane application is anything close to plain English, but it's much better than custom data formats and regex.)

        • Re: (Score:3, Informative)

          To me that says that XML handles a problem that wasn't there. Parsing problem for pretty much everything is almost universally solved by regex...
          God, no... another Perl hacker...

          Regex are not a solution to everything, and most certainly not to writing fast parsers!

          (Not that XML is easy to parse fast, but that's another story. You still don't write a JSON parser using regex.)

  • XML and Interfaces (Score:3, Insightful)

    by PIPBoy3000 ( 619296 ) on Monday February 18, 2008 @12:46PM (#22464422)
    I realize the XML is used for a lot of things, but whenever my fellow developers learn that the vendor is shipping us some interface in XML, the groans are audible. About half the time, their XML format isn't quite standard, and we've got to dig around for utilities to try and work with it (or write something custom). I'd say the vast majority of our interfaces are good ol' delimited text files.

    For other purposes, XML is great and very readable, but I'm not sure it makes sense to use it everywhere.
    • by MBCook ( 132727 ) <foobarsoft@foobarsoft.com> on Monday February 18, 2008 @01:02PM (#22464622) Homepage
      Here are some of the "fun" things I have run across in other people's (almost certainly custom) XML interpreters/producers:
      • Tags must be upper case
      • Tags can't be upper case
      • You must put line breaks between elements
      • There can't be any whitespace between elements
      • It's import to URL encode the XML before it gets sent from them to me
      • You don't need CDATA blocks, just put the ampersands and >s right in there, it'll be OK
      • Your XML should all be inside a CDATA block in container XML
      • No tags can self-close
      • Self closed tags need a space between the slash and bracket
      • Self closed tags can't have a space between the slash and bracket

      That's just what I can think of off the top of my head. We've seen quite a bit of crazy stuff. If everyone would just use one of the already written XML producers or parsers (the big ones, the ones that work) life would be much easier around here from time to time.

      • by trolltalk.com ( 1108067 ) on Monday February 18, 2008 @01:33PM (#22464988) Homepage Journal

        If everyone would just use one of the already written XML producers or parsers (the big ones, the ones that work) life would be much easier around here from time to time.
        If everyone would just went back to using simple delimited ascii text life would be much easier around here.

        • That will work until you need to use non-ascii content, to include the delimiter in the data itself (so that you need an escaping mechanism), you want to represent hierarchical data, you want to be able to compose data from different sources without semantic collisions, and what not.

          So you solve these issues, turning for `simple delimited ascii text' format into something a bit more complicated, and next you will be wantint to interchange instances with others, so you will have to start coming to an agreem

          • "That will work until you need to use non-ascii content, to include the delimiter in the data itself (so that you need an escaping mechanism), you want to represent hierarchical data, you want to be able to compose data from different sources without semantic collisions, and what not."

            Using a single null (0x00) to delimit each field, and two nulls to delimit each record, is UTF-friendly. As for non-ascii contents, just encode them in base64 (which you would probably be doing anyway in a cdata section).

            • So you do not see the use of empty fields?
            • And what if you are not dealing with a table with record and fields but with a tree?
              • "And what if you are not dealing with a table with record and fields but with a tree?"

                Trees and graphs are not a problem - just like they aren't in regular table design (though it IS ugly). One field holds the parent node record id, or is blank if its a top-level node. A second field can hold the node type. Extend your schema as required.

        • by CaptainPinko ( 753849 ) on Monday February 18, 2008 @03:22PM (#22466350)
          ASCII doesn't even support the letters needed by the majority of the world's language.
          • "ASCII doesn't even support the letters needed by the majority of the world's language."

            UTF does - so just use UTF - no big deal, and a lot easier to parse out than xml, which is butt-ugly to parse, terrible to index, doesn't support random access read/write, etc.

      • My experiences with some of generic XML parser is not very good. (Technically speaking we are dealing here with lexical scanners, not parsers.) Especially the SAX interface is not a pretty one. It is a typical interface that was designed from the inside (the parser) point of view, but not from the user point of view. Also, because XML is very rich, and you hardly every use all of this richness, there is always a performance penalty. If you have to parse megabyte size of XML files that you know only make use
    • by Aladrin ( 926209 )
      It never makes sense to use any 1 thing 'everywhere', but if people would actually stick to the standard and use it intelligently, XML could be very beneficial.

      Unfortunately, as you point out, very few do. I'm sick of not-quite-standard crap as well. It's a nightmare to work with... Even moreso than no standard would have been.
  • Considering all the (internet, and elsewhere) crapola that gets passed around as XML, with pretty much anything-you-want included, I don't really understand how we can call it "formalized".

    Add to that the fact that then the ability to "display" XML comes down to the whatever-you-want-to-write manner, and I think there are plenty of people who would be hard to convince that there really is a "formal standard" for XML.

    Perhaps Duke Nukem Forever will be written with this fantastic standard?
    • by Jerf ( 17166 ) on Monday February 18, 2008 @01:43PM (#22465116) Journal
      Yes. XML was formalized. It is strictly defined and easy to check for compliance (with the right tools). Only a little bit of the definition has passed out of common usage, mostly focused around DTDs.

      If you encounter a file that claims to be XML, but does not meet the XML standard, then it is not the XML standard that is to blame. The claim is wrong and the file is not XML.

      XML is not a fuzzy-wuzzy adjective that can be applied willy-nilly to anything and magically turn it into "XML". It is not a marketing term or English Professor term. It is a rigidly specified engineer term for a document format, and a given document is XML if and only if it meets that format.

      If someone wants to hack together a half-assed parser or emitter of any language, they will. I've seen half-assed XML parsers, I've seen half-assed JSON parsers, I've seen half-assed HTML parsers, I've seen half-assed YAML parsers, I've seen ... you get the idea. If a standard can't solve the problem, you can't count the lack of solution against it.
      • If a standard can't solve the problem, you can't count the lack of solution against it.

        Forgive my lack of knowledge on XML - I primarily just see bad implementations of it.

        But what problem was XML supposed to solve? Exactly who/what/where was in need of an extensible markup language, anyways?
  • I've recently taken a job at a primarily Java shop. After seeing XML used and abused for ant, maven and various other things I've grown even more disenchanted with it. And now I've also gotten the chance to see that not only does Java represent a poor trade off between the annoyances of a strongly typed language and the speed of a dynamic interpreted one, it has a horrible mess of dependency issues that nobody really solves besides.

    I'm much more hopeful about technologies like Thrift [facebook.com] and/or D-Bus [freedesktop.org] than I ever was about such abysmal abominations as SOAP, or the only slightly better XML-RPC.

    The Java XML world seems like this little closed ecology of mutual masturbators who all come up with more Java and XML 'solutions' to problems that never existed before they started using Java and XML.

    I see the value of XML for long-lived documents that don't spend a lot of their life on the wire. And possibly for config files, though IMHO it is too ugly and unreadable for those. But as a general tool for Internet plumbing it's awful.

    • by Omnifarious ( 11933 ) <eric-slash@om[ ] ... g ['nif' in gap]> on Monday February 18, 2008 @01:03PM (#22464632) Homepage Journal

      And, of course, my post is incomplete with reference to my little rant on why CORBA and other forms of RPC are bad [omnifarious.org]. Both Thrift and D-BUS are pretty close to the ideal solution I describe later. They focus on message content over semantics and are extremely easy to parse. SOAP and XML-RPC fail on both of those counts. They are about semantics (you are making a remote function call that does some specific thing, not sending a hunk of data that has some particular content) over content and they are a huge pain to parse.

      • Re: (Score:3, Interesting)

        CORBA uses IDL for interface definition. Therefore, you don't even have to write code to parse it: the parsing code is generated automatically. So the arguments about parsing are non issues. With regard to content, one can define content in IDL very easily. I have not used the APIs you refer to (e.g., Thrift), so I cannot comment on those. I will say this though: when I used to write apps 10 years ago using CORBA, it took me so little time to throw a system-to-system interface together that I almost didn't
        • CORBA is a minor pain to parse. From what I could tell you could just sit down with a spec and code up your own parser for ye-old random language in a day or two. But that's not my major issue with it.

          My major issue with it was that it promotes designing distributed systems that focus on the semantic roles of the participants instead of the data moving around. In fact it discourages programmers using it from even thinking of what they're doing as sending messages to some system many milliseconds away. Among other evils this leads to all kinds of interesting issues with threading and concurrency that didn't even have to exist.

    • I do a lot of Java and XML. I don't know what you're using for a library, but I'd suggest JDOM.

      As for the abuses for Maven and Ant... yeah. I'll agree. There are a lot of things that seem to use XML just because they can. I know there is some theory behind why they use them (machine readable, blah blah blah) but for most things it's just a giant pain for the complexity you get. Maybe if you were trying to build Windows with Ant.

      • by bckrispi ( 725257 ) on Monday February 18, 2008 @01:36PM (#22465024)
        I'll take an Ant XML build file over an "is that a tab or a space" Makefile any day...
      • Re: (Score:2, Informative)

        by fartrader ( 323244 )
        Java is clearly moving away from the massive over-use of XML in everything from configuration to messaging. From Java 5 onwards, annotations are rapidly becoming the configuration mechanism of choice, where infrastructure configuration is placed in the source code directly, in a way thats significantly less obtrusive than writing code to manage things like persistence and transactions yourself, and significantly easier to follow than placing it in many XML files. Anyone who has migrated from EJB 2.1 to 3.
    • by GodfatherofSoul ( 174979 ) on Monday February 18, 2008 @01:24PM (#22464864)

      Yay! Nothing like the combination of XML and Java to bring out the haters. Incompetent use of a language/API doesn't equate to a bad language/API. I can show you plenty of crappy C/C++ code freely browsable in some open source libraries. Does that mean C++ sucks? Hell no.

      My experience with Java+XML you ask? OFX servers for financial institutions. Without name dropping, check out the list of banks, brokerages, tax services, and credit card providers [microsoft.com] (Quicken [microsoft.com]) out there successfully serving up client data. I guess we're all circle jerking while you're downloading your account information into Quicken or Money.

      Some good uses for XML:

      • Ephemeral representations of atomic, structured data; usually for transport.
      • Config files. More verbose and the syntax is far better at keeping you from fat fingering a setting and blowing up your app. If you can't clearly read XML, you need glasses.

      Some bad uses for XML:

      • High volume, rapid response data streams; like say an on-line multiplayer game (though I've never benchmarked this)
      • Unbounded data streams; e.g. streaming media
      • Databases

      I have to admit, I'm clueless about your Java dependency issues. The only way I can see that ever happening is if you're dumping all of your classes into the default top-level package; and that's major user error if you are.

      • by nguy ( 1207026 )
        Incompetent use of a language/API doesn't equate to a bad language/API

        No, but incompetent design of a language/API does, in fact, equate to a bad language/API.
      • OFX servers for financial institutions. Without name dropping, check out the list of banks, brokerages, tax services, and credit card providers (Quicken) out there successfully serving up client data.

        I'm aware of OFX, and it is something I consider a non-evil use of XML. It is all about the data, and the data is high-volume, structured and text-like, so something like XML makes sense for representing it.

        OTOH, name dropping gets nowhere with me. Large institutions routinely adopt very stupid technologies for the most ridiculous of reasons. I'm much more interesting in what a small, nimble high-tech company like Automated Trading Desk [atdesk.com] is doing than what Chase-Manhattan is doing. Of course, ATD appe

        • by MBCook ( 132727 )

          That's Maven's job. It's supposed to get all the JARs you tell it to.

          It's not Maven's job to figure out if you actually use a JAR (which gets complicated when code depends on JAR A, which depends on JAR B, which....).

          The usual way to handle something like this is to use Maven to keep things up to date on your machine. You can deploy all those JARs with your program (as you seem to be doing) or you can keep them somewhere else on the server and update them manually. Maven makes sure you have the requisite

      • That's because OFX IS A DEFINED STANDARD - a standard driven by Intuit. I guess you're too young to remember NPC - a competing standard? Or having to support BOTH? Oh yeah... that was great fund.

        You tell me what is a standard in Ant? Nice taking his comments out of context.
      • Some bad uses for XML: Unbounded data streams; e.g. streaming media

        The success of XMPP, which is entirely centered around the concept of an XML stream, seems to disprove this.

        Databases

        Normally true, but for small catalogs of a few hundred records at most, one may consider XML for its ease of handling and recoverability.

        Also, for tree-like structures, XML/XQuery databases can often beat relational (once you start getting into 10+ joins in the latter, that is). Of course good XML databases don't really st

      • I have to admit, I'm clueless about your Java dependency issues.
        Usually this is because the container you are using depends upon version X of XML Library A (usually to read it's own config files, or other boring stuff) while some your own code or some third-party API you use depends upon version X+1 of that same Library A. It's not an impossible problem to get around, but it's a problem that exists in almost every non-trivial app I've ever worked on.
    • In general, if you have data to be structured and serialized, XML is one way to do it. If you think XML a poor choice, then could you suggest an alternative? Incidentally, that suggestion should not imply that everyone reinvent their own formats (again).

      [N]ot only does Java represent a poor trade off between the annoyances of a strongly typed language and the speed of a dynamic interpreted one ...

      Would you provide evidence aside from personal anecdotes, and possibly consider evidence to the contrary [wikipedia.org]?

      • by hoggoth ( 414195 )
        > If you think XML a poor choice, then could you suggest an alternative?

        YAML for the win!
        YAML is concise, easy to read, easy to write, easy to parse, easy to edit.
        It has high signal-to-noise ration, and is effortless for the human eye.
        It can represent any data structure I can imagine.
        It has libraries for any popular language I can think of.
      • Re: (Score:3, Informative)

        by argent ( 18001 )
        If you think XML a poor choice, then could you suggest an alternative?

        Depends on the problem you're trying to solve.

        A hell of a lot of the stuff I'm seeing in XML these days would be better off as token-separated self-describing tables (tables where the column names are the first row), or a modestly extended token-separated format like CSV.

        For binary data something derived from Electronic Arts semi-self-describing interchange file format is good, examples in current use are MIDI File Format and Portable Net
    • Java and XML are similar in that both of them got over-hyped. They're also similar in that sometimes they really are the right solution -- just not as often as PHBs seem to think. I've had exactly one application where I started designing the file format, and realized, "Oh heck, I'm reinventing XML," so I went with XML and it was the right choice. For config files, the advantage I can see is that although XML may not be optimal for every type of config file, it does provide an alternative to the traditional
    • I don't know about Thrift being a real contender in the web/internet-based services area. Really, code generation? How 80's. Haven't we learned enough from Sun RPC that this is a PITA, give me a proper library dammit! And AFAIK D-Bus is for local IPC, good luck sending messages over a network without a couple of hoops to jump through.

      I can see your viewpoint, if you want to squeeze as much performance out of your application you might want to investigate Thrift, D-Bus or simply write your own TCP protocol.
  • Oblig (Score:5, Funny)

    by mariuszbi ( 1113049 ) on Monday February 18, 2008 @01:00PM (#22464598)
    XML is like violence.. when it doesn't work, use some more!
  • I recently began testing some RSS and Atom parsing modules for Movable Type that I wrote, and noticed that they were breaking on different feeds that Google Reader handles easily. When I looked at the RSS and Atom markup, I noticed that the reason was that the various generators that were causing problems weren't always generating RSS and Atom in the way that I expected. WordPress.com, for example, was using content:encoded tags for some of the content for blog posts, and had an empty description tag in tha
    • by EMN13 ( 11493 )
      Semantics are difficult. XML does not solve semantic issues like what tags mean. Be happy if your RSS provider provides syntactically valid XML - at least you can unambiguously interpret the structure of the document now!

      As to semantics, if you're trying to interpret such a home-grown format as atom/rss, without reference implementation (and most specifically without a good test), your problems lie not with XML, but with that spec.

      And indeed, RSS and atom aren't very good in that sense. It may be hard to
  • XML doesn't seem like a big deal. SGML was around since the mid-80s, making it over 20 years old. XML is stricter in many ways, and layers some useful concepts on top of SGML. But otherwise it seems to have a lot of the same uses and syntax as SGML itself.

    As a side note, I dislike it when people use XML inappropriately, like using XML-RPC when something based on ASN.1 might be more appropriate. (How many wannabe MMORPG projects have I read that are "XML-RPC" based? too many). I'm sure there are good uses fo
  • by hey ( 83763 )
    There needs to be some description of an XML lite.
    For config files and such.

    - No doctype needed
    - tags are case insensitive
    - Can do comments with # character instead of
    - Etc

  • TFA is a fun read. Too bad XML sucks. As Jerome and Philip Wadler write [ed.ac.uk], "[T]he essence of XML is this: the problem it solves is not hard, and it does not solve the problem well."

    Lisp had the same problem solved 40 years earlier. While a lot of people find S-expressions verbose, XML is quite a bit more verbose. Slava Akhmechet has a nice essay [defmacro.org] on the relationship between the two notations.

    • by 5pp000 ( 873881 )

      Whoops -- the authors of the linked paper should have been given as Jérôme Siméon and Philip Wadler. Sorry for the error.

    • by Shados ( 741919 )
      Really, XML does solve the problem. The only issue with it, is that its designed to solve ALL problems, instead of using the usual 80/20 rule... instead of being optimized for most problems, it uses the lowest common denominator to try and catch the 20 other %...and everything that makes XML suck comes from that extra 20%.

      If it was easier to handle dates in JSON without schemas, we'd have one heck of a winner there though.
  • what happened with DBASE and its kin. It's easy enough to use that any idiot can...and you end up with schema that reflect that idiocy.

    XML isn't the problem. Idiots writing XML is. I'm beginning to think that a certain level of difficult is necessary as a screening device.

MAC user's dynamic debugging list evaluator? Never heard of that.

Working...