

An OPML like exportable format for Todo Lists? - arpit
http://www.arpitonline.com/blog/2010/11/07/an-opml-like-exportable-format-for-todo-lists/

======
rwl
Ugh, why can't this person have a simple comment form? Even enabling all the
scripts on the page, I can't seem to post a comment on the blog. So here's the
one I wrote...

 _Have you tried Org Mode? (<http://orgmode.org>)

I find it totally indispensable for keeping track of all of my Todo items --
and a lot more besides. It has exporters for various formats, including HTML,
PDF/LaTeX, and plain text. Rather than storing your data in the inaccessible
cloud, it encourages you to store your Todo files locally, but makes it easy
to sync them (e.g., with a service like Dropbox). External projects like
MobileOrg for iPhone (<http://mobileorg.ncogni.to/>) and Android
(<http://matburt.net/?p=94>) provide a way to read Org files on your mobile
device.

I realize that sounds like a bit of a commercial, but the point as it relates
to your post is this: the Org format, which is a plain text format, is already
a rich representation for task management. It is used by several different
apps, and already has exporters for other formats. You could always extend Org
to export to OPML like you have envisioned, too, without too much work. There
is a lot of work being done on exporters these days, and I think you would
find good support in the community if this was a project you wanted to work
on._

~~~
arpit
Good point, I haven't used emacs in 8 years, but I know a couple of developers
who use it with a lot of passion, even though I imagine its hard for non
developers to use it. But using the formal exported by that may not be a bad
idea.

I would love to flesh out the core elements (the model in the MVC sense)
required that defines a task and its context. The format itself could be
exportable as XML, JSON or Org-Mode consumable files.

PS: Sorry about your issue with Disqus, I actually recently installed it
because it allowed me to connect with the commentors even more since they
signed in with Twitter etc. I should probably look into some graceful
degradation back to core wordpress comments when needed.

~~~
rwl
_Good point, I haven't used emacs in 8 years, but I know a couple of
developers who use it with a lot of passion, even though I imagine its hard
for non developers to use it._

Well, don't be afraid! I'm not a "developer," and I do 99% of my work in
Emacs. (I am a philosophy student, though I do write programs from time to
time.) It takes time to learn, but so do all worthwhile things.

 _I would love to flesh out the core elements (the model in the MVC sense)
required that defines a task and its context. The format itself could be
exportable as XML, JSON or Org-Mode consumable files._

Well, as far as Org is concerned, the core elements that define a task are:

1) Title

2) Todo state (user configurable: mine goes TODO -> INPROGRESS -> [possibly]
WAITING -> DONE)

With the following optionally present (I'm sure I'm missing some; this is off
the top of my head):

\- Priority (also user configurable)

\- Description/free-form notes

\- Deadline timestamp (may be recurring)

\- Timestamp indicating when task is scheduled

\- Timestamp indicating when task was finished

\- running tally of time spent so far

\- a list of arbitrary tags

\- a list of arbitrary properties (key/value pairs)

\- a parent task

\- a list of sub-tasks

\- a property indicating whether sub-tasks must be completed in order

This is all I need in a task model, and then some. You would probably also
need a model to represent more global context (like the todo state-flow
graph).

Of course, Org also comes with a rich set of tools at the "view" layer, too,
which I recommend looking into.

 _Sorry about your issue with Disqus, I actually recently installed it because
it allowed me to connect with the commentors even more since they signed in
with Twitter etc._

No worries; it comes with the territory when you're a paranoid NoScript user.
(That said, I wasn't even able to post the comment after allowing all scripts
on the page, so a fallback is probably in order.)

------
tjpick
I would first read Tim Bray's "Don’t Invent XML Languages"
[http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-
XML...](http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-
Languages)

Then use html's list structures, possibly with a microformat. Or maybe atom.

~~~
zdw
While I really dig Tim Bray's work, I tend to think it's very easy to get the
wrong impression from his statements in that post.

The point he's making is that, in most cases, you should use an existing XML
schema instead of reinventing the wheel - it's bad to have a NIH attitude. For
the post that started this discussion, an extension or modification on the
iCalendar todo specification would make the most sense.

The problem comes when you're trying to describe something totally new, or in
a use case that deviates greatly from things that have come before - for
example, I'm working on a network description schema for a project, and I
haven't found anything similar, although it is informed by other schemas, from
a variety of places (nmap's, and a few others mainly). Had there been prior
work that matched what I was trying to do, I'd use it, but as there isn't,
it's totally justified to create a new schema in this case.

------
yaxdotcom
Exportable/importable ToDos would be good. But online ToDo lists with APIs are
the future. Like Toodledo: <http://api.toodledo.com/2/index.php>

Are there others with APIs?

------
pwpwp
Atom + a custom XML namespace should be uncontroversial.

~~~
tommorris
Please, no. Keep Atom for feeds please. I really don't like people shoving
everything into Atom feeds. For a todo list, damn, either plain text (OrgMode
or something similar) or HTML.

