Slashdot Mirror


Tim Bray on the Birth of XML, 10 Years Later

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?'"

4 of 260 comments (clear)

  1. Re:Java and XML - Addendum by cjonslashdot · · 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 even think about it. The same with EJB, except that persistent EJBs were flawed and so EJBs lost credibility even though the API model (similar to CORBA) was (and is) extremely easy to use. Then people started wanting to communicate across firewalls, and OMG didn't get its act together and make IIOP capable of traversing firewalls before people got hooked on hand-coding HTTP messaging, which then led to XML messages and SOAP and Web services. The right answer was to fix the OMG spec for pushing IIOP through firewalls in a standard way. Nowadays, whenever I have to create an inter-system interface and the options involve SOAP or Web services or some other XML-based interface, I groan and it takes me ten times as long to get the interface built and reliable. That is not progress. I will look at Thrift and the other API that you mention, and we may disagree on some thing (e.g., the value of type safety), but I agree with you that XML-based messaging has been a huge, huge step backwards.

  2. Re:Java and XML, bad tastes that are worse togethe by GodfatherofSoul · · Score: 5, Interesting

    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 (Quicken) 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.

    --
    I swear to God...I swear to God! That is NOT how you treat your human!
  3. Re:Classic by fireboy1919 · · Score: 3, Interesting

    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.

    --
    Mod me down and I will become more powerful than you can possibly imagine!
  4. Re:Here, let me fix that for you ... by thrillseeker · · Score: 3, Interesting

    I knew we would (d)evolve to punch cards eventually.