Data model - what data is being represented?

The Cornell method of note taking - is a tree structure with "heading" and "paragraph" really the best description? Or is it more like "tag" and "blogpost"? -pete

I'd like to keep the data model as general as possible (arbitrary tree), and make the default behavior to restrict it to a single layer of headings. So I want to stick with "headings" and "paragraphs" for now. What do you think? I might not be getting what you're driving at. -saketh

Since Notalon is based on the Cornell system of note taking... I assumed that would be the way we handle data?
Oh, and, this specification probably needs to be split into two:
a) What is the internal data model for the notes? (which is what we're discussing - how do we "think" about the notes)
b) Data import and export - which the specification addresses in it's summary. -pete

Data model white paper can be found at the linked address. Pending final approval until Saketh has taken a look, and had a go at the code. -petemyers

I like the clarity of the specification! I agree with the Note class fully. I see the purpose for the Page class -- to make the implementation of summaries natural -- but I feel like it's best for now to stick with just the Note as you've defined it as the base class, and insert summaries as Notes. Although this doesn't perfectly mimic the Cornell style, it will simplify the data model significantly. I will go ahead with this subset of the specification you've written, because should we need it the Page-based structure could easily be added later through subclassing.

So just to clarify, the new spec would be just a class Note with a heading field, a content field, and a list of tags -- a subset of your specification for now. Is this OK with you?

-saketh

Actually... I'd quite like the specification met. I reckon I could handle data import/export tomorrow if I have the classes written. You can meet the specification by writing three classes: A class that contains the methods and properties common to both Notes and Pages, and then just extend that class with Notes and Pages. It shouldn't be too much work. If it is, do you want me to do it? -petemyers

Pete will implement the whole specification, and Saketh can confirm whether the implementation covers the needs he has. As it is - if Saketh wants a "tree" https://blueprints.launchpad.net/notalon/+spec/tree like structure for Notes, then a Page class is *necessary* to hold Notes together in a hierarchy (it's not very object oriented or sensible for the Notes to record their own place in the tree). I'll mark that as a dependency. - petemyers