Ten Predictions for XML in 2007

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."

I've got some.

[Anonymous Coward]

It will still be used as the wrong tool for the job. People will still design schemas with a 15:1 bloat:actual-data ratio. It will find itself used in applications which benefit not at all from any of its strengths, but those strengths will be the selling point.

XML is broken

[oohshiny]

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.

Re:XML is broken

[Osty]

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.

Re:My hope..

[gregmac]

Oh, so then I can take my XML from my subcontractor engineering software:

<info>
  <building>
      <foundation>
          <cost>400000</cost>
      </foundation>
      <insulation>
          <cost>200000</cost>
      </insulation>
      <roof>
          <style>flat</style>
          <cost>300000</cost>
      </root>
  </building>
</info>

and import it into your software? Sweet!

Perhaps you mean, that your software understands "whiz-bang engineering interchange files" (which happen to be XML-based).. which was my point, there is a distinction.

Re:My hope..

[Anonymous Coward]

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.

Re:XML is broken

[Osty]

Here's a quick test: do you check the XML document in to your version control or configuration management system? Then it's code.

Oddly enough, I also check-in READMEs, SETUPs, images, doc files, etc. None of those are code, and neither is my XML configuration file (for example).