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

Comments

Re:How about reasons not to use XML?

[Osty]

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.

My hope..

[gregmac]

..that XML will stop being a buzzword, and we will no longer see products with "XML support" as a feature point (supporting formats that USE XML is fine, but "XML" itself is a container format, it can describe literally ANYTHING..)

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.

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:XML is broken

[YA_Python_dev]

pick one of the better alternative formats and convert to XML after editing

Well said. A good example is RELAX NG: write the source in the compact syntax and convert it to XML when/if you need it.

A simple compact syntax example:

start = element title { text }*

The equivalent XML (and the RELAX NG XML format is considered much better than, e.g., W3C XML Schema):

<grammar xmlns="http://relaxng.org/ns/structure/1.0">
_ <start>
_ _ <zeroOrMore>
_ _ _ <element name="title">
_ _ _ _ <text/>
_ _ _ </element>
_ _ </zeroOrMore>
_ </start>
</grammar>

(Please ignore the underscores.)

Remember people: XML may be good for data interchange between different applications because every language ever created by the gods has an XML parser, but don't use it for anything else. To quote Phillip J. Eby: Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems.

Re:XML is broken

[mrchaotica]

To quote Phillip J. Eby: "Some people, when confronted with a problem, think 'I know, I'll use XML.' Now they have two problems."

And I have a t-shirt that says (in the style of those motivational posters) "Abstraction: because the first step in solving any problem is always to create more problems." So, does that mean abstraction is bad, too?

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

JEdit

[CaptainPinko]

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.

Re:XML and Web services

[jma05]

SOAP is typed. XML-RPC isn't. So SOAP is easier to work with in conjunction with stub generators in statically typed languages. Dynamically typed languages are better off with XML-RPC.

A better comparison is - Is SOAP any better than CORBA for what SOAP is being used for. It was initially sold with the "port 80" and "easier to debug than a binary protocol" arguments. Those don't hold much water any longer. Further, SOAP added a ton of extensions obliterating any ease of use promises, a trap that CORBA itself fell into. Heck, even the basic WSDL spec turned out to be difficult enough that stub generators aren't available for most languages. Python recently got one last week, but dynamic languages mostly went without.

If all that one does is typed stateless procedural calls, CORBA is hardly anymore complex than SOAP and heck of a lot more efficient than SOAP.

Re:Who else was hoping...

[uradu]

In my experience those who hate it the most are those who understand it the least.

Re:How about reasons not to use XML?

[Bastard of Subhumani]

That's why I gave up using bitmap images. Looking at the picture, dividing it into a grid of units (I call them pixels, short for picture elements - cute, eh?), estimating the RGB values, converting them to hex and keying them in just got to be too much effort.

Re:Who else was hoping...

[Wiseman1024]

I'd kill XML in favour of either:

- A standard binary, binary-safe serialization format that allows you to serialize simple objects: int, float, (unicode) string, list of any of these types and dictionary of int, float or string any of these types.

- A real, binary-safe, flexible grammar processing tool that allows you to define grammars in EBNF and process them (preferrably, constructing and deconstructing the parse tree), being standard, clean, and multi-language. This will allow you to work with XML as well as other existing exchange formats (INI, CSV, etc.) and absolutely anything else.