On Apr 14, 7:07 pm, "Edward K. Ream" <[EMAIL PROTECTED]> wrote: > On Mon, Apr 14, 2008 at 4:52 PM, Edward K. Ream <[EMAIL PROTECTED]> wrote: > > Of course, if you must, you can base your product on the old world. It's > > > always a valid option. > > On second thought, this isn't nearly good enough for you. No way do I want > to consign one of Leo's most important users to obsolete status. > > Instead, my mission is to solve your transition problem in a way that > clearly works better for you than the old way. I want you to be an > enthusiastic supporter of unified nodes. Nothing less will be good enough > for me.
Johannes, when I awoke this morning, I realized that your objections are much more important than I realized at first. This may be an opportunity in disguise, or it may spell big trouble for the unified- node world. More invention is required, perhaps theoretical, perhaps practical. Several question appear, at different levels of the design/ implementation hierarchy: 1. Perhaps most importantly, in the unified-node world, are Leo outlines a proper representation of a DAG? If so, what is the graph- theoretical correspondence between the graph and Leo nodes? That is, suppose two nodes in a directed graph "point to" a shared node. What is the corresponding outline in the unified-nodes world? Does the notion of cloned node "shift" in the unified-node world. That is do, different kinds of nodes get a clone mark? 2. How do clones get a clone mark? :-) This morning I realized that the code for setting the clone mark has no chance of working: another data structure (a node ivar) will be needed. Could this data structure be used to disambiguate different instances of the *same* node? 3. Are cloned nodes properly updated in synch? That would seem to be guaranteed, because cloned nodes are the *same* node, but now not even that seems certain. Or rather, it's not clear that the same nodes get cloned marks in the new world. I was lead to these question by considering another question. In the unified-node world, could we create a notion of "joined" nodes that are *different nodes* such that some or all aspects of the different nodes get updated in unison. For instance, we could conceive of different nodes whose headlines Leo guarantees to be the same. Or body text. Or children. Or uA's. This kind of joining is a frequently requested feature. Is it easier in the unified-node world? Or does it, as seems more likely, lead us back to the same problems as existed in the ancient Leo world where no subtrees were shared? 4. Can we create a natural mapping from CDISC Operational Data Model to unified nodes? Would that mapping use clones in the same way? Is there a mapping that uses clones in a different way, but would be just as useful, or as seems likely to me, even more useful. I'll be looking at this model in much more detail now that the stakes seem so much higher. In short, the initial clarity has turned murky again. As always, this is a sign that more invention is needed. I believe the driving force behind the new inquiry will be a comparison of how DAG's are represented in the old and new world. For sure, we can not commit to the unified-node world until all such issues are resolved to everyone's satisfaction. Including you, Johannes :-) I'll be exploring these issues from the top down, theoretically, and from the bottom up, by debugging the unified-node code. It may be that there will be surprises when I create clones in the new world. Those surprises could highlight further problems, or suggest clearer solutions. Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
