Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ten Predictions for XML in 2007

Posted by CowboyNeal on from the crystal-balls dept.

An anonymous reader writes "2007 is shaping up to be the most exciting year since the community drove off the XML highway into the Web services swamp half a decade ago. XQuery, Atom, Atom Publishing Protocol (APP), XProc, and GRRDL are all promising new power. Some slightly older technologies like XForms and XSLT are having new life breathed into them. 2007 will be a very good year to work with XML."

5 of 71 comments (clear)

  1. Re:How about reasons not to use XML? by Osty · · Score: 5, Informative

    There's one reason I like JSON way more than XML, and its name is RSI.

    If you're getting RSI from XML, you're not doing it right. Use a tool! Anyway, the real reason to use JSON instead of XML is cross-site security restrictions. You can't make an XmlHTTPRequest call from one domain to another, but you can add a <script /> tag with a src pointing somewhere else.

  2. XML is broken by oohshiny · · Score: 4, Insightful

    If you're getting RSI from XML, you're not doing it right. Use a tool!

    So, you're saying that in order to use a markup language whose primary design goal was to be easy for human beings to work with, I should invest in buying and learning at tool? Never mind that I have never even seen a decent XML editor.

    Sorry, but XML is just bad design: it's badly designed for machines, and it's badly designed for humans. Using tools to deal with it may be a workaround, but it's certainly not "doing it right".

    In fact, the best compromise is probably simply not to write code in XML, but pick one of the better alternative formats and convert to XML after editing.

    1. Re:XML is broken by Osty · · Score: 4, Insightful

      So, you're saying that in order to use a markup language whose primary design goal was to be easy for human beings to work with, I should invest in buying and learning at tool? Never mind that I have never even seen a decent XML editor.

      No, I'm saying that you should rarely have to edit XML directly yourself. For the times that you do, use a nice programmer's editor like PSPad or Visual Studio that will automatically add close tags (cut your typing in half!). The rest of the time, you should be generating your XML programmatically from some other data source.

      In fact, the best compromise is probably simply not to write code in XML, but pick one of the better alternative formats and convert to XML after editing.

      Since when is XML "code"? Writing an XSL/T to apply to an XML file may be code-like, but in general XML should be a data format that you pass around between applications, not something you "code" yourself.

  3. JEdit by CaptainPinko · · Score: 4, Informative

    May I suggest JEdit? It supports XML out-of-the-box and is open source and runs anywhere and is a great* editor by any measure. If after having your XML closing tags auto-completed, indented, and validated effortlessly in this editor leaves XML still too much work for you, then I hope you never use anything beyond Vi, APL, and LaTex.**

    *I said "great" not "perfect". Lets keep this civilised.

    **Nothing wrong with any of these: just examples of the tersest things of which I could think.

    --
    Your CPU is not doing anything else, at least do something.
  4. Re:My hope.. by Anonymous Coward · · Score: 4, Insightful

    Write a CSV parser, and then you can say that working with flat text files "is meaningless." It's harder than people think. The PHP fgetcsv() function gets it wrong right off the bat by forgetting that a newline can appear within a quoted field.

    What a world we live in, when knowing and doing more is derided just because it isn't buzzword compliant.