[Couchdb Wiki] Update of "SchemaForToDoList" by JensAlfke

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "SchemaForToDoList" page has been changed by JensAlfke:
http://wiki.apache.org/couchdb/SchemaForToDoList

New page:
= Proposed Schema For To-Do Lists =
Created by JensAlfke on 6 Aug 2011

== Introduction ==

The to-do list seems like a good use case for CouchDB: it's got a fairly well-defined data format; queries are pretty straightforward; it's a very popular type of application; and transparent syncing is a crucial feature.

By defining a standard base data schema for applications to use, they can easily interoperate on a single data store, even if some apps add extra metadata.

=== Applications ===

Some apps I looked at, and/or have used myself:
 * [[http://culturedcode.com/things/|Things]]
 * [[http://www.omnigroup.com/products/omnifocus|OmniFocus]]
 * [[http://www.rememberthemilk.com/help/guide/|RememberTheMilk]]
 * [[http://www.6wunderkinder.com/wunderlist|Wunderlist]]
 * [[https://www.producteev.com|Producteev]]

== Feature Set ==

=== Level 0: Required ===

The essential features of a to-do list are very simple. We need a set of items with the following properties:

 * Title
 * Completed, aka Checked

That's it, really. Couchbase's current mobile demo app has only these features, and it's actually useful in the real world. 

=== Level 1: Common ===

When you look at real to-do list apps, they all have many of the following extra features:

 * Star / Flag, or a range of priorities
 * Creation Date
 * Due Date (optional)
 * Notes
 * URL Link
 * Tags
 * Multiple named lists, where each item can be in one list at a time.
 * Hierarchies of lists
 * File attachments

=== Level 2: Advanced ===

Some extra features found in higher-end list apps:

 * Custom re-ordering of items in a list
 * Hierarchies of items
 * Recurring tasks that respawn on a schedule (weekly, first Tuesday of the month, etc.)
 * Percent complete
 * Estimated time
 * Reminders at some interval before the due date

I'm not going to address these here. Maybe in a future update to this spec.

== Document Schema ==

=== Item ===

 * "type": "todo", required
 * "title": string, required
 * "check": boolean, defaults to false
 * "priority": boolean or number, defaults to false
 * "created_at": date-time*
 * "modified_at": date-time [not necessarily visible to the user, but useful in conflict resolution]
 * "due_at": date or date-time
 * "notes": string
 * "link": string [a URL]
 * "category": string, defaults to "INBOX" [name of list this is in]
 * "tags": array

* Dates and times are specified in ISO-8601 format, which appears to be the de-facto standard used in JSON. A "date" doesn't contain the time portion of the string. Times should all be given in GMT to allow for easy sorting via collation.

File attachments can be stored as, well, attachments. No need to define a specific schema for them.

=== Category ===

For the most part the list of categories can be derived from the union of the "category" values of all "todo" items; but that implies that categories with no items in them cease to exist, which isn't good! Defining an explicit document type also leaves open the option of adding metadata to categories in the future (e.g. colors or descriptions.)

 * "type": "category", required
 * "name": string, required
 * "parent": string

It's not necessary for every category to have its own "category" document. In other words, the application's UI should show a category for every unique "category" value that appears in a "todo" document, whether or not there's a "category" document for it. Otherwise a list item can disappear from the UI if its category document is renamed without updating its "category" value, which can happen during replication.

''Question:'' Should we instead use a more normalized relation, where the todo item's "category" value is the _id of its category document? On the plus side, this allows renaming a category without having to update every item in it. On the minus side, it could cause problems when merging. (For example: on one device I add an item to a category, and on another device I delete that category. After syncing I'm left with an item pointing to a nonexistent category _id.)