views:

96

answers:

5

I'm writing an application that manages todo lists. Unlike 'traditional' todo list applications I want users to have these todo list files sit on their filesystem and be visible instead of being magically hidden by the app. I want users to be able to email todo lists to each other and so on. In addition, I later intend to create a web app with a database backend that will allow users to collaborate on todo lists.

The question I have is, what file format should I use to store the local files of my application? When I started thinking about this, the first think that came to mind was XML because it's (somewhat) readable but then I thought about sqlite then found out about YAML and now I'm quite confused. Some guidance would be appreciated.

Update:

I should mention that I will most probably be coding this in C++, Objective C or (not very likely, though) python. So whatever format is proposed it needs to have appropriate libraries.

Update 2:

I'm also concerned about being able to associate all these different formats with my applications so when opens a file of my application format, my application opens up instead of something like a text editor.

A: 

What about using sqlite in your app and adding an export / import functionallity that would export/import those lists in xml?

Maxem
Frankly, since XML and YAML are human readable it would be great for debugging, I'm not sure if it'll provide other advantages over binary formats such as SQLite.
Pilgrim
A: 

I would say XML, but even as I suggest this, I get a feeling that since you asked this question, I recommend that you get a programming book on this topic and start reading.... Is this for a school project?

JasonMichael
No, not a school project.Why would you suggest a programming book?
Pilgrim
I'm asking because the design considerations for your project seem horrible. Why would you have database files available for the user to see and screw up? Who's going to support this product when a user has full reign of the text file and the program can no longer read it?
JasonMichael
+2  A: 

I'm a big fan of using SQLite databases as document files (gives you structure, a good analysis tool, transactions, etc); but if you want the user to simply take the document and email it, a robust text-based format would be much better.

XML is a possibility; but it's far too verbose and ugly. YAML is a lot more readable, it can look like an .INI file, but with more structure. JSON is an intermediate, not as readable as YAML, not as ugly as XML.

All three formats can take any arbitrary structure, produce the text-based representation and reconstruct the structure from it, so they're functionally equivalent.

The main advantage of XML seem to be that it's easy to detect when it has been accidentally damaged, because it will no longer be a well-formed document. But it's not hard to add some checksums or similar fields to any format.

Javier
What would the advantages of JSON over YAML be then?
Pilgrim
@Pilgrim: very few. first of all, it's more widely used, so it's easier to get support libraries and interoperation. but in this case i think it's important to note that JSON termninates all its structures (strings are quoted, arrays finish with ']' and tables with '}'), while YAML can (optionally) express structure with whitespace (indentation, line ending, etc). it's more human-readable, but i think it would be a little easier to damage by handling on email (by adding '>', inserting extra empty lines, or truncating)
Javier
+2  A: 

Another alternative, especially if you want to be able to embed other content into your documents such as images, is to use a packaging file format. The advantage is that users only will have to send a single file, which has all content embedded. Another advantage is that large XML structures can be well compressed.

Examples of such formats are ODF (OpenDocument Format), which uses a zip package containing a manifest file, or Office OpenXML, which uses an OPC (Open Packaging Conventions) container. Both formats are standardized by ISO.

0xA3
A: 

If you want users to be able to edit the files as text, then any of the text formats should be fine and it's more a matter of preference than anything else.

If you don't want users to be able to edit it as text (less chance of them messing up the data accidentally) and instead they edit the file through your application only then I'd go with Sqlite.

Regarding associating the file format, you don't associate formats, you associate file extensions, so if you don't want them to be associated to another app, make up your own file extension and register your app to it.

Davy8