E.g. for note-taking programs: sometimes you want a note within a note, a note attached to a note.
E.g. for calendar programs:
- notes on calendar items
- links between calendar items
- to-do lists and checklists attached to calendar items
For to-do lists and checklists:
- notes on the top level lists and checklists
- notes on individual items
- links to calendar items
- checklists nested within checklists
- checklists nested within each other and linked to each other
- e.g. when I go travelling on business I take all of the electronics I lug around every day, ++
For reminders: (which I am only recently realizing are distinct objects in their own right)...
You get the picture: all of the basic data types of my imaginary PIM (Personal Information Manager)
- text notes
- drawings and bitmaps (e.g. screen captures, although I still like vector grapics)
- time scheduling and tracking
- recording: diaries, logs, and journals
- scheduling and planning: calendars and schedules
- hey, writing this made me realize that schedules and to-do lists and checklists are related
- e.g. might want to reuse a schedule/plan for arranging a trip or a meeting - I guess that is like a template for a trip on a travel website - and when instantiating such a template drop items onto your calendar/schedule relative to the target date (although likelihood is that you will tweak the dates
... and I am sure that I have forgotten some ...
All need the ability to be embedded in other objects, and to have other objects embedded in them.
(I want to say "of course there will be leaf types" ... but do there need to be? Can we come up with a rendering scheme that is completely self recursive, without having to introduce leaf types (like TextNote, versus TextNoteThatCanHaveOtherStuffEmbeddedWithinIt). Certainly a data representation like XML, without DTDs, can be completely self recursive[*])
([*]: actually, it seems, based on tests, that DTDs permit recursion. Which is okay by me: I like being able to have DTDs, as long as they can be optional.)
