starting a brainstorming page - Re: [uf-discuss] Re: Actions
cayle.graumann at gmail.com
Wed Nov 1 22:28:01 PST 2006
I've finished reading the iCalendar spec (RC2445) and it looks
like the spec prohibits nesting of vtodo's either inside of a vevent
or another vtodo, and it prohibits nesting a vevent in a vtodo. The
spec allows a vtodo to be related to another vtodo, a valarm or a
vjournal and maybe to a vevent (the spec is unclear on this - under
vevent it says it can be related to a todo, but under todo it lists
all the others and leaves vevent off), through the "related" property.
A vTodo is essentially just a vevent with more properties both at the
conceptual and fieldname levels. So much is the same between vevent
and vtodo that it makes me wonder why they didn't just add the few
different fields to vevents rather than put them vTodo. They may have
been trying to make the parsing simpler or maintain compatibility with
an earlier implementation, I guess. The other major thing different
between them is that a vTodo is free/busy neutral, while a vEvent can
be used in the free/busy operation. I guess that the thought is that
a vTodo can either be done or not done and that it doesn't preclude
you from and doing something else.
The precedent has already been set for extending the iCalendar spec in
hCalendar, with the recommended use of embedded hCard instead of
simple strings for ATTENDEE, CONTACT, and ORGANIZER.
a side by side comparison of vevent and vtodo:
end vevent/end vtodo
As you can see, the vtodo adds complete, percent, and due to vevent, and drops
transp and dtend. I think we should for a first try take hCalendar
vEvent as authoritative and build from there. After that I think that
I'll take a crack at defining the rstatus and related properties to
implement the 7 or so relationships I emailed earlier. I've been
meaning to get a trial basecamp account and test it for work anyway,
so I'll see what kind of vTodo's it exports. MS Project doesn't
directly support vTodo that I'm aware of, but it does have an XML
output which I was going to see how well it might map to vTodo's. In
fact one of my goals in this is to be able to transform that MS
Project XML into whatever we come up with, either that or query the
Project database directly which may actually be easier.
On 11/1/06, Cayle Graumann <cayle.graumann at gmail.com> wrote:
> I let you take a first crack at it as I'm pretty busy myself with
> work and won't be able to get to anything past re-reading in depth the
> iCalendar RFC until Saturday Morning (Central US Time). It looks like
> we have our work cut out for us though. At the outset, I think we
> will need use cases showing embedding both hCalendar events in hTodo
> structures and hTodo structures in hCalendar.
> For my scheduling data, I think it would be good to have a standard
> way to say the following:
> 1) whether a todo item depends on an outcome of another todo item.
> (todo conditional branching)
> 2) an item must be complete before another begins (tail-head dependency)
> 3) must be complete before another can complete (tail-slide dependency)
> 4) must be complete at the same time another is complete. (tail-tail dependency)
> 5) must be started at the same time as another item. (head-head dependency)
> 6) must be begun, but not necessarily complete, before another can
> start (head-slide dependency).
> 7) must be done at exactly the same time as another (head-head
> tail-tail dependency)
> I don't yet know whether the iCalendar spec already has a defined
> approach for these kind of relationships between todo items. If it
> does, great! and we should use that, if not, then I guess we'll have
> some more thinking to do.
> Cheers to you too,
> On 11/1/06, Justin Thorp <juth at loc.gov> wrote:
> > I am busy until later this evening but I would be happy to take a first pass at a todo microformat brainstorming page, unless you want to.
> > Cheers,
> > Justin
> > ******************
> > Justin Thorp
> > Web Services - Office of Strategic Initiatives
> > Library of Congress
> > e - juth at loc.gov
> > p - 202/707-9541
> > >>> cayle.graumann at gmail.com 11/01/06 4:32 PM >>>
> > Interesting discussion here. I was thinking about todo lists and
> > calendar events myself as I'm trying to figure out how to markup
> > project management data using microformats on the web that could be
> > automatically scraped to generate Gantt chart-like output, as well as
> > potentially being pulled into a program on a PDA.
> > On 11/1/06, Rob O'Rourke <rob at sanchothefat.com> wrote:
> > >
> > > Justin Thorp wrote:
> > > > Why does an action or todo microformat have to be something that you do on the page? Maybe I want to pull the ToDo out of the page and put it on my 30Boxes ToDo list or Outlook or something.
> > > >
> > > >
> > > It doesn't, you're right but I was ignoring the to-do idea when I
> > > replied, I was referring to the actions you can carry out with a
> > > microformatted page like exporting the uF or emailing someone, I just
> > > misunderstood.
> > >
> > > > You should be able to nest an hCard inside of a ToDo.
> > > >
> > > > I can see this type of microformat being helpful in a situation where I have information for a rock concert but I have to buy the tickets for the rock concert.
> > > >
> > > > So while the event information is marked up in an hCalendar that I can download, there is also a ToDo marked up that tells me to buy a ticket and where I can buy it. I could grab this info and import into my ToDo list.
> > > >
> > >
> > > Would these todo 'actions' be marked up within the event to give them a
> > > deadline? or a completely separate list that has its own time-frame (or
> > > none at all) and perhaps uses something like .include to refer to the
> > > event in question?
> > In my case, I have a series of calendar events that lead up to the
> > completion of one TODO item, but I could see where you might have a
> > list of TODO items that need to be completed at one calendar event
> > also.
> > >
> > > > Cheers,
> > > > Justin Thorp
> > > _______________________________________________
> > > microformats-discuss mailing list
> > > microformats-discuss at microformats.org
> > > http://microformats.org/mailman/listinfo/microformats-discuss
> > >
> > Cayle
> > Missouri
> > _______________________________________________
> > microformats-discuss mailing list
> > microformats-discuss at microformats.org
> > http://microformats.org/mailman/listinfo/microformats-discuss
More information about the microformats-discuss