On Apr 15, 2:01 pm, "Edward K. Ream" <[EMAIL PROTECTED]> wrote: > > No way do I want > > to consign one of Leo's most important users to obsolete status.
I hope there are more "important" (by any metric) users of Leo than myself. > 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? My take on it is as follows: The current implementation represents a vertex- and edge-labelled DAG. Unified nodes lose the possibility to label edges. > 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? I suspect most of the requests stem from misplaced analogies about object inheritance or parameterised macros. > 4. Can we create a natural mapping from CDISC Operational Data Model > to unified nodes? Very obviously, one can always map a vertex-and-edge labelled graph to a vertex labelled graph by substituting edge, annotated vertex, edge for annotated edge. If you mean by "natural" "intuitive to the user", I would tend to "no". The intermediate (or "auxiliary") nodes should at best not be visible to the user. The CDISC Operational Data Model is represented in XML, and it uses the crutch of --Ref and --Def elements and OIDs to embed shared subtrees and DAG structure in the tree structure of XML. This is OK for a data interchange format to be read by machines, less than OK for me when I write XSLT filters and not so nice for human reading. It is like reading separate table of a relational database and jumping from table to table looking for matching foreign keys. Leo in its future form solves the DAG problem. Leo in its present form solves the annotation of edges. > I'll be > looking at this model in much more detail now that the stakes seem so > much higher. This is most considerate of you and much more than I can expect from a free software project. > For sure, we can not commit to > the unified-node world until all such issues are resolved to > everyone's satisfaction. Including you, Johannes :-) If this is the case, I'll warm-heartedly embrace the change. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
