Hal Fulton wrote: > That may be true, but if the API is a "simple consequence," I would guess > that the data model is pretty heavily specified. Well, a conceptual model describes a state space, and should contain the business rules that restrict legal states in that space. ER models are more limited than ORM models in their ability to represent the rules. By describing what can exist, the API flows as "how to create, search, update and delete" every state that can exist. It's always simple to design an API for a good conceptual model. > The key is a unique string assigned to each item. Ok. This is the hierarchical thing. In some DBMSs it would be a simple numeric RID (Record ID), but that doesn't assist in subtree searches. If you guarantee that for any object, a child-ID will never be re-used, you create a useful unique-for-all-time hierarchical ID. > Did you mean "topic OR note"? Yes. >> Functionality questions: >> * When you change the root topic of an app, what happens to all the >> now unreachable topics and notes? Is the change persistent? Perhaps >> you could replace this problematic operation with a simple "flip >> parent and child" operation? > That's also unclear to me at this time. I was thinking along the lines > of a Unix "chroot" operation -- "pretend" that this subset of the tree > is the whole tree for now. Not sure this concept is useful. If it's not persistent, I'd leave it out. Any search operation should be able to take a context object and function from that. You might also consider a "new window from here" type operation that creates a new view of the topic tree from that point down. But this is just a presentation thing. For persistent tree changes, the "flip parent and child" is a useful op. If the new parent is to "adopt" all the children of the old parent, that will change values propagated into the children. >> (BTW, this isn't inheritance I believe, but propagation down >> the tree - is that right?). > I'm not sure what you mean. There are probably good reasons not to call it > inheritance. But it's not simple cascading, i.e. doesn't affect siblings. A sub-topic, or a note in a topic, which uses a value defined by its parent object, is experiencing value propagation rather than inheritance, since the child isn't derived from the parent through inheritance, but contained in a parent-child relationship. I note that you don't make any mention of actual inheritance. That simplifies things, but don't confuse the parant-child relationship with an inheritance one. > It sounds like you're talking about multiple "views" of the data, is > that correct? It does give you that capability, but it's more than that. Essentially an observer has a topic of interest (what I call an aspect), and when looking at or for a target object, they see only those attributes (and children, if that's implemented) which are relevant to that topic. > I'm halfway following this, though it's confusing. How would you > propose to store all this? I've been through many models for that, and the simplest is to just store each child item (a reference to a sub-topic or note, a value for a variable) with its "pertains-to" value, in a single place, serialised with the object, regardless of its relevance (aspect). > It does sound powerful, but I wonder 1) would it require a full-fledged > database? and 2) wouldn't it require an awful lot of disk access to > store things in a "scattered" format? No. There's no *need* to scatter things. You could label an aspect such that all items which pertain to it are out-of-line (not stored directly in the parent object), which allows control of clustering, but it's not necessary. For example, you could choose to store all GUI layout values away from the objects to which they pertain... but it's not needed in a simple tool. The important thing is to allow the *viewer* to see only the data which are relevant to their search, without having to create "metadata" categories to store other things (like layout info etc). The key observation of aspect-oriented modelling is that for any subject, there is a potentially unlimited number of categories of descriptive information - each category being a different aspect. I use the term "facet" to describe the facts for an object which pertain to a given aspect. For example color is an aspect, green is the color facet of "grass"). You can think of a facet as being like a programming-language "interface" - one object may have any number of interfaces. This argues that though the database must know *all* the attributes of an object, any given API for that object must assume that the object has more attributes than the API shows - that is, it only ever returns interfaces. Any query searches an aspect, and only relevent facets of the result objects will be visible without further searching. Clifford Heath.