Hi , The RSF file is based on the RIGI Standard Format (hence, "RSF"), but it has been substantially altered to enable the addition of attributes to relations and hierarchy elements. I'll explain it below. Let's take a look at the header first (I'm using the provided JHotDraw RSF file (initial) as an example): "LevelSeparator" "." This indicates what kind of separator symbol is used for separating level entries later on in the file, i.e., "root.level.sublevel.element"; I would leave that set to ".". "ElmType" "0" "Class" "ElmType" "1" "Package" These entries indicate that there are two types of hierarchy elements: "Classes" and "Packages". They should be sorted alphabetically on the third column and they should increase numerically on the second column, which contains the unique ElmType IDs. ElmTypes are not optional; you should have at least one ElmType present, which might be a dummy entry like "ElmType" "0" "Dummy" or something. "RelType" "0" "CallDynamicChronologic" "int:Increment" "sig:Signature" "string:Method" This entry indicates that there is one types of relation: "CallDynamicChronologic". RelType entries should be sorted alphabetically on the third column as well and they should also increase numerically on the second column, which contains the unique RelType IDs. RelTypes are not optional either; you should have at least one RelType present, which might again be a dummy entry. As far as the attributes are concerned, the following is important: first we have one or more "int" attributes, all of which are ordered alphabetically (on the name after the type, i.e., "Increment" in case of "int:Increment"), then we have one or more "sig" attributes, all of which are ordered alphabetically, and finally there we have one or more "string" attributes, all of which are ordered alphabetically. The current version of the tool requires at least one "int", one "sig" and one "string" attribute, so you should use dummy variables for that in the example at the end of this mail. "HierarchyDepth" "7" Maximum depth of the hierarchy; an example element having depth 7 is "org.jhotdraw.test.util.collections.jdk12.CollectionsFactoryJDK12Test". "HierarchyElements" "550" The number of elements in the tree, including the root. "ParentChildRelations" "549" The number of tree links, i.e., parent-child relations (not the links (calls) among tree nodes). "Signatures" "651" Number of elements in the signature list; this is only important for our own data; you can set it to 1 and add a dummy element to the signature list later on (I will explain this in a small example at the end). "Relations" "13642" Number of relations among tree items (excluding the parent-child relations). "Root" "0" The hierarchy element ID for the root element (in this case "org"; it's normally always 0, but we're leaving it in for now). Okay, now comes a list of hierarchy elements. It looks like this: "H" "0" "org" "1" "H" "1" "org.jhotdraw" "1" "H" "2" "org.jhotdraw.TestAll" "0" "H" "3" "org.jhotdraw.applet" "1" "H" "4" "org.jhotdraw.applet.DrawApplet" "0" "H" for hierarchy element, followed by the ID, followed by the name of the element (full name; the list of hierarchy elements is also sorted alphabetically (and using case sensitivity, i.e., capital letters first) on this third column), and finally the ElmType ID that was defined earlier to indicate if - in this case - the hierarchy element is a Class or a Package. Okay, the next block is a list of parent-child relations (together with the hierarchy elements defined above they form the tree structure): "PCR" "0" "1" "PCR" "1" "2" "PCR" "1" "3" "PCR" "1" "5" "PCR" "1" "7" This means that hierarchy element with ID 0 is the parent of hierarchy element with ID 1, hierarchy element with ID 1 is the parent of hierarchy element with ID 2 etc. The next block contains signatures (you might construct this list by using a single dummy entry, i.e., "S" "0" "DummyFunctionPrototype" "DummyFile" "DummyLineNumber"). A signature starts with "S", followed by a unique ID and three string containing the actual signature (one for the function prototype, one for the file where the function resides, and one for its line number within the file): "S" "0" "public abstract java.util.List org.jhotdraw.util.CollectionsFactory.createList()" "org/jhotdraw/util/collections/jdk12/CollectionsFactoryJDK12.java" "105" "S" "1" "public void org.jhotdraw.application.DrawApplication.setDefaultCloseOperation(int)" "org/jhotdraw/samples/javadraw/JavaDrawApp.java" "106" "S" "2" "public void org.jhotdraw.application.DrawApplication.setApplicationName(java.lang.String)" "org/jhotdraw/samples/javadraw/JavaDrawApp.java" "107" The final block contains the relations ("calls", if you will) among hierarchy elements. Every relation starts with "R", followed by the hierarchy element ID of the calling element, followed by the hierarchy element ID of the called element, followed by the RelType ID. Due to the fact that the RelType ID is 0 everywhere in this data set and since RelType 0 corresponds to "RelType" "0" "CallDynamicChronologic" "int:Increment" "sig:Signature" "string:Method", there will be three additional columns - "int:Increment", "sig:Signature", and "string:Method" - for each relation. As you can see, the values of these fields are "1759", "541", and "setEventDispatcher(org.jhotdraw.standard.AbstractCommand.EventDispatcher)", respectively, for the first relation: "R" "6" "6" "0" "1759" "541" "setEventDispatcher(org.jhotdraw.standard.AbstractCommand.EventDispatcher)" "R" "6" "6" "0" "1756" "313" "createEventDispatcher()" "R" "6" "6" "0" "1776" "313" "createEventDispatcher()" This is basically all there is to it. To make sure that the tool accepts your data, I would advise you to have at most one RelType in your data set (more specifically, exactly the one that is shown above, i.e., "RelType" "0" "CallDynamicChronologic" "int:Increment" "sig:Signature" "string:Method"), one or more ElmTypes, and a single signature. What follows is an example of how the tree and relations shown at http://www.win.tue.nl/~dholten/extravis/images/tree.jpg can be described using an RSF file: "LevelSeparator" "." "ElmType" "0" "DummyElement" "RelType" "0" "CallDynamicChronologic" "int:Increment" "sig:Signature" "string:Method" "HierarchyDepth" "3" "HierarchyElements" "13" "ParentChildRelations" "12" "Signatures" "1" "Relations" "6" "Root" "0" "H" "0" "A" "0" "H" "1" "A.A" "0" "H" "2" "A.A.A" "0" "H" "3" "A.A.B" "0" "H" "4" "A.A.C" "0" "H" "5" "A.B" "0" "H" "6" "A.B.A" "0" "H" "7" "A.B.B" "0" "H" "8" "A.C" "0" "H" "9" "A.D" "0" "H" "10" "A.D.A" "0" "H" "11" "A.D.B" "0" "H" "12" "A.D.C" "0" "PCR" "0" "1" "PCR" "0" "5" "PCR" "0" "8" "PCR" "0" "9" "PCR" "1" "2" "PCR" "1" "3" "PCR" "1" "4" "PCR" "5" "6" "PCR" "5" "7" "PCR" "9" "10" "PCR" "9" "11" "PCR" "9" "12" "S" "0" "DummyFunctionPrototype" "DummyFile" "DummyLineNumber" "R" "2" "5" "0" "DummyIntegerValue" "0" "DummyString" "R" "3" "4" "0" "DummyIntegerValue" "0" "DummyString" "R" "7" "10" "0" "DummyIntegerValue" "0" "DummyString" "R" "8" "6" "0" "DummyIntegerValue" "0" "DummyString" "R" "9" "8" "0" "DummyIntegerValue" "0" "DummyString" "R" "12" "10" "0" "DummyIntegerValue" "0" "DummyString" By the way, "PCR" and "R" entries are first sorted numerically on the first column and then on the second column (so they are sorted on the first two hierarchy element ID columns). Well, that was a lot of info, but I hope that it helps to clear things up ;-). Regards, Danny.