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.