Slashdot Mirror

← Back to Stories (view on slashdot.org)

XML Is Too Hard, Part 2

Posted by timothy on from the most-things-are-too-hard dept.

orangerobot writes "A new article on XML.com summarizes some of the response from the XML-DEV mailing list to Tim Bray's recent comments about his frustrations with XML. The overall feedback is mixed but several parsing packages are mentioned that satisfy some of Bray's complaints about the difficulty of using DOM and SAX-based APIs. The packages include Pyxie, XML::Filter::Dispatcher and XML::Essex."

6 of 17 comments (clear)

  1. Related rants by madmaxx · · Score: 4, Informative

    Jorn at robotwisdom has been ranting about XML for a years now.

    xmlsucks.org has a whole wiki of xml rants.

    The Advogato has discussed xml evils at least once. There are more rants in the user journals if you've got time to search.

    XML is just a text markup - a very verbose, flexible one at that. It's not much different than a good hammer. Great tool for pounding nails ... but not everything is a nail ...

    --
    mx
    1. Re:Related rants by Anonymous Coward · · Score: 2, Insightful

      Jorn at robotwisdom is an idiot, so I wouldn't put too much faith in what he says. Likewise for anybody immature enough to register a 'sucks' domain. Funny you should mention Advogato, as the last article there basically said that a hell of a lot of the articles posted there are just plain wrong.

      XML is just a text markup - a very verbose, flexible one at that. It's not much different than a good hammer. Great tool for pounding nails ... but not everything is a nail ...

      Precisely. But for all the hype, I haven't seen anybody claiming otherwise, so that's a strawman argument. Even the W3C doesn't say that XML is the solution to everything.

  2. See also... by vbweenie · · Score: 4, Interesting

    ...this thread on Lambda the Ultimate for a recent discussion of issues related to Bray's article.

    --
    Experience is a hard school, but fools will learn no other.
  3. go for implementation-specific by ProfKyne · · Score: 3, Insightful

    DOM seems like a good standard to have around, but if you really want ease of use and don't have to worry about making your code portable across different languages, go for one of the more implementation-specific APIs. JDOM looks really cool -- at least, it looks very natural if you're a Java programmer.

    --
    "First you gotta do the truffle shuffle."
  4. As always... by Millennium · · Score: 3, Interesting

    The real problem is that XML got so overhyped that now people want to use it for everything.

    I mean, come on. XML is a good tool for a lot of things. But what reason is there to, for example, create a language which translates between XML formats in XML? That could just as easily have been done in another format, and would probably have come out looking a lot nicer.

    As for the API's being too difficult: well, it is programming (which has some level of difficulty inherent in it, though it need not be absurdly tough). Besides which, the API's were meant to be generic, and you know what they say about jacks of all trades. Implement your own API, on top of SAX or the DOM (you'd probably get better efficiency if you used SAX, but the DOM may be easier for some programmers), and you'll have something what's easier to work with for your particular project, without sacrificing the portability that SAX and the DOM bring. Seriously, it's just a matter of coming up with creative solutions.

    By the way, am I the only one who's thinking of doing a satirical cartoon zbout this mess? Like maybe a Barbie doll that says "XML Is Hard" or something like that?

    1. Re:As always... by rbolkey · · Score: 3, Insightful

      Although I agree with your point that XML is overhyped and people are thinking about using it in cases where it may not be useful. I also think the opposite extreme, bashing every use of XML, is a little short sited.

      You're not saying everything xml is bad, but while not being sure how much you've worked with xslt, I have to disagree with you and say that it's rather nice and useful for the task it was designed for. Using a well-formed description to manipulate another one seems logical to me. The syntax is all uniform, which is nice (if you've every looked at what PHP looks like embeddeded with HTML, you'll know what I'm talking about).

      And without the language, which echos of Prolog and Lisp to me, people would probably use procedural methods common to what most people are used to, instead of a more recursive model that lends itself well to document processing. I'm scared to think of what a procedural type language defined in XML would look like, but recursive instruction look quite elegant.

      I, for one, just think it was a wise path to take for a needed tool.