views:

719

answers:

16

XML, granted, is very useful, but can be quite verbose. What alternatives are there and are they specialised for any particular purpose? Library support to interrogate the contents easily is a big plus point.

+10  A: 

There seems to be a lot of multi-platform support for JSON.

spoulson
+1  A: 

S-Expressions work great if you don't need to apply attributes to elements. Another alternative is YAML.

Ugh
+6  A: 

Don't forget about YAML!

JSON seems to have better support though. For example, the Prototype JS library has excellent built-in JSON functions.

Mark Biek
+8  A: 

Jeff's article on The Angle Bracket Tax summarizes a number of alternatives (well, mainly YAML), and led me to the wiki article on lightweight markup languages.

harpo
+1  A: 

I wouldn't dismiss plain text, like CSV or tab-delimited.

Thomas Owens
+1  A: 

For the sake of completeness I will mention Edifact for which I wrote an interface a long time ago.

Aranazo
A: 

JSON is valid YAML which could be very useful. Two for one!

Adam Lassek
+1  A: 

XML is often used for configuration, and in this case there are some other simple storage formats that are often used (less document oriented):

  1. .property files
  2. INI files

There's various ways for reading and writing both, depending on platform and language.

Simon Steele
+2  A: 

What do you want to do with the data? Store it? Pass it around? Display it? These questions should drive your search for an appropriate technology. Simply asking how you should format your data is like asking what language you should program in, without specifying what you want to accomplish.

For most data tasks, well Dr. Codd has the cure: http://en.wikipedia.org/wiki/Edgar_F._Codd. Databases should be able to do just about anything you have in mind.

If you're passing it around, I advocate plain text. When you roll your own binary format your data goes away when your parser goes away.

With plain text, the deeper question is where to put the metadata. Should it be external to the data file, or internal ("self-describing").

For example, XML is plain text, but so is source code. With a source file, there is a specification that goes in to great detail as to the syntax and semantics, while XML is supposed to be self-describing. The problem is that it isn't. Furthermore it evolved right out of document presentation and markup, but is now being abused for all sorts of data serialization, transfer, and storage.

fatcat1111
A: 

If you're asking in the perspective of a DSL, Guile Scheme could help, as already suggested with the S-expressions.

Personally I also use JSON for AJAX transactions.

+2  A: 

HDF5 is a very compact data format with some characteristics that are similar to xml. The .net libraries leave a lot to be desired, but the format scales very well both in terms of size and performance.

Timothy Carter
+1 for a small, fast, cross-platform **binary** format. Why are all these flabby, slow, text formats so popular? (Please, everyone, don't claim XML is human-readable.)
MarkJ
+1  A: 

I wouldn't dismiss plain text, like CSV or tab-delimited.

I'm really looking for alternatives that have a defined structure and (cross platform, multi language) library support. I'm interested in looking at different designs and their pros and cons. I like the idea of formats that can have a text and "binary" (compact, "compiled", fast I/O, smaller footprint) format. The advantage of having libraries is that they perform the parsing and perhaps extra data manipulation/validation for you.

Although having said that, there is definitely a use for simple formats like .ini, .plist and CSV etc. You shouldn't always have to use a hammer to crack a nut.

Nick
+1  A: 

But at what cost?

I'm all for JSON in many situations, especially where weight or client-side work is a concern, but moving away from XML loses readability (so important in those config files) and the power of tomorrow's problem solutions like XSLT and XPath. Be really sure why and when you move away: it's a de facto standard for a reason.

(aside: my habit is to use XML internally, and transform that to JSON where that's the desired output)

annakata
+1  A: 

My work with XML is almost exclusively with document-centric XML, which must model long sequences of arbitrarily nested structures. I haven't used JSON yet, but my impression is that it is cumbersome to use with document-like data, but well-adapted and even elegant for use with record-like data. Consider the shape of your data when making your decision.

ChuckB
+1 Xml is a good match for documents
Robert Gould
+1  A: 

Heresy! XML is king of data. Say no to the usurpers, off with their heads! Long live XML!

But seriously if just need data use Json, for support and elegance, but if you need formating ,xpath like queries, additional metadata, etc... Stick with XML

Note: I use Xml for configs system building code generation and similar tasks, but Json for Rpc,Sql for queries and persistency, and finally Yaml here and there for logging and quick tasks, in other words choose the appriopiate format for the need.

Robert Gould
+1  A: 

You could try google's protobufs. It's much faster than XML. There are libraries for it in C, C++, C#, Java and Python (there are alpha versons for ruby and perl). But it is binary.

paperhorse