Hi Seref, Interesting thought! I think this comes down to a design choice, which is whether we want to force single-rooted tree. By definition, tree data structure has a single root. But when we model hierarchical structure of clinical content, it's convenient to allow multiple nodes at the top level of the tree without the need to create a root node just to satisfy the notion of single-rooted tree. So it's a choice between purity (according to computer science definition of a tree) and convenience (which somewhat indirectly translated to usability of the model and relevant tools).
Cheers, Rong 2009/4/1 Seref Arikan <serefarikan at kurumsalteknoloji.com>: > Hi, > Why is "item" field of Item_tree of type List<Item>? I feel that it is > causing a litle bit of overlap betwen Item_tree and item_table. Item_table > has a rows property with type List<Cluster>, which is nice for representing > multi column tables, but when it comes to a single column table, item_tree > also seem to allow it, by using a List<Element> given that items property is > List<Item> > Would not it be better to enforce semantics of a tree structure by making > item property of Item_tree a single Cluster ? Then the meaning of the > elements of the cluster would be enforced by the container class, item_tree, > where each member of cluster (whether cluster or element) would mean a new > row in a tree. This would also force a tree with a single parent node, but > it would still allow expression of a tree. > Not a big deal, but I think it would be better to force the semantics of a > type to make its use as clear as possible. Care to show me if I'm missing > something? :) > > Kind regards > Seref > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
