• Introduction
• Schema specification
• Storing your tuples
• Attribute section
• The $ROOT entity
• Files without schema and layout
• Example

Introduction

LSEdit is a program for viewing and editing software landscape files produced by software reverse engineering tools, including the QLDX pipeline. LSEdit is not specific to any one domain, however, and can be used for visualizing anything that can be represented as a "landscape". Visually, a landscape consists of multiple types of boxes contained in other boxes, and linked by arrows.

What is a landscape? A landscape is a graph conforming to a certain structure. To be more specific: it is a graph with multiple named types of nodes and multiple types of edges. At least one type of edges must be called "contain" and form either a tree or a forest connecting all nodes in the graph. This edge type is treated specially, in that it denotes the containment structure of the landscape. Other edge types do not have any restrictions - they can cross containment levels, form loops, etc. Both nodes and edges can have additional attributes, specifying their names, types, ways to display them, and their other various properties.

Landscapes are stored on disk as TA (Tuple-Attribute language) files. This guide assumes that you are already familiar with TA, and refers to various TA concepts without explaining them. If you are not familiar with the Tuple Attribute language, please see the introduction to TA for more information.

Naming Convention. Landscape files are commonly given the ".ls.ta" extension, to signify that that they contain a LandScape and are in Tuple-Attribute format. Landscapes that end in the suffixes, ".zip", ".gzip" and ".jar" will be decompressed as read using the appropriate decompression algorithm. As a special case, specific files contained within such compressed files can be obtained by appending the named file to the suffix, enclosed in square brackets. When files are being remotely read, as would be the case when using java applets, compressing landscape files, can result in significant performance improvement, particularly across slow lines.

[top]

Schema specification

The optional schema of a landscape declares what entity and relation types the landscape can contain, and what kinds of relations are allowed between what kinds of entities. The attribute section of the schema also specifies what attributes relations and entities can have, and the default values of the attributes (if any).

An entity or relation can only appear in the attribute section of the schema (SCHEME ATTRIBUTE :) if it was mentioned in the tuple section of the schema (SCHEME TUPLE :); otherwise, LSEdit will generate an error and refuse to recognize the existence of entity or relation class.

Schema enforcement. LSEdit uses the schema only to determine what entity and relation types exist, and what their attributes are. Every type of entity and relation that exists in the landscape must be somehow mentioned in the schema; any entity or relation type that does not appear in the schema will be ignored if it is encountered later on in the landscape.

Otherwise, LSEdit is very lax in enforcing the schema; in particular, it will allow entities to contain other entities, and relations to link entities even if the schema does not explicitly allow such containment or linkage to exist.

[top]

Storing your tuples

The $INSTANCE relation. TA is a declaration-before-use language, and declaration is implemented through the $INSTANCE relation. For every entity (i.e. node) in the landscape, the $INSTANCE relation should specify what class it belongs to. Mentioning an entity in a relation other than $INSTANCE until its class is known is considered to be an error by LSEdit (and some other software that handles TA) so it is advisable to put the $INSTANCE relation above all other relations in the landscape file, at the beginning of the first "FACT TUPLE :" section.

Containment. LSEdit assumes that containment information is stored in a relation called contain; this is the relation LSEdit picks to form the hierarchy, unless a different relation is specified in the landscape file. The edges of this relation must form a tree or a forest. Circular containment or multicontainment (one box contained in many others) are not tolerated by LSEdit and will cause errors. If the contain relation does not specify containment information for a particular entity (e.g. the root of the tree), this entity is assumed to be contained is a special entity called $ROOT. This entity is internal to LSEdit and does not have to be part of your landscape; $ROOT cannot be contained in anything. The $ROOT entity has a separate section devoted to it below.

A landscape can have several relations which can form a containment hierarchy - any relation that forms a tree or a forest is a valid candidate. LSEdit allows for switching between containment hierarchies; a check for tree-ness (or, more properly, forest-ness) is made before the switch is made.

[top]

Attribute section

While certain attributes are understood by LSEdit, any named attribute may be associated with any landscape object. Those having no special semantics within LSEdit will be read, remembered in memory, editable, and subsequently preserved in any saved landscape. If the ability to validate that attribute names are legitimate attribute names that are used should be declared in the schema section. However this is optional.

Below you will find a listing of the attributes that are treated specially by LSEdit, their possible values, and the effect they have on their entities or relations.

Landscape object attributes
id	All landscape objects have an id established when these objects are declared. The id of relations is derived from the relation class and the entities connected by the relation. This attribute may not be changed within LSEdit.
color	The color attribute specifies the desired color of a landscape object, and for entities (boxes) specifies the color of that entity when it is closed (see also attribute opencolor). Objects that lack such attributes inherit their color attribute from their nearest superclass that has such an attribute. The color is set by assigning a three-value (red,green,blue) list of integers , each in the range 0 to 255, to the color attribute. For example, to set the color to red, the following assignment will be needed: color = (255 0 0) An optional fourth color component may be specified. This value specifies the transparency of the resulting color. This is the degree to which objects obscured by objects having such a color will continue to be painted. A value of 255 indicates that the color is opaque, and no dithering of the underlying object color will be performed. a value of 0 indicates that the color is entirely transparent, making the obscured object color entirely visible. If not specified this value defaults to 255. A recent enhancement to LSEdit permits colors to also be computed relative to the class to which the object being assigned a color belongs to. An integer color component preceded by '+'/'-' implies that the color is to be derived by adding or subtracting (modulo 255) the indicated shift to the color of this objects superclass. A double precision value preceded by '*' indicates that the same color component in the superclass is to be multiplied by this value in deriving the desired new color component. The following named colors may also be specified: "black", "blue", "cyan", "gray", "green", "magenta", "orange", "pink", "red", "white" and "yellow". Such names may optionally be preceded by the word "dark", or "light" to darken or lighten the named color.
labelcolor	The labelcolor specifies the color of any label to be associated with a landscape object. Its value is specified using the same syntax as that described for color.
Landscape class attributes
class_label	This attribute species the label to be associated with a class. If a class has no explicit class label, its internal id is used as a suitable substitute for the missing label. This attribute is considered private and is not inherited.
class_description	This attribute provides a class with a long form description that may be shown in tool tip popups, etc. Like the class_label, this attribute is not inherited.
class_active	This attribute specifies as a boolean true/false value, whether instances of this class are to be initially considered active when queries are made against the landscape.
class_visible	This attribute specifies as a boolean true/false value, whether instances of this class are to be initially considered visible when the landscape is loaded.
Relation class attributes
class_rlabel	The class_rlabel attribute provides the desired name for a relation class when the direction of this relation class is reversed. If absent when relations are reversed their label becomes their class_label (if any) followed by "(r)".
class_style	The class_style attribute determines the appearance of relations associated with this class. Relations having no style attribute inherit the class_style as their style attribute. When associated with relations class style is an integer and can have the following values: normal - edges are to be drawn normally dashed - Edges are to be dashed dotted - Edges are to be dotted inscribed - Edges are to be inscribed The class_style attribute can only be set on a class-wide basis; use the style attribute to change the look of individual arrows. An example landscape which shows all arrow classes can be seen here.
arrowcolor	An optional feature when visualising landscapes is to associate a color not only with relations but also with arrow heads used to represent these relations. This attribute specifies that optional color. The feature is enabled and disabled by setting the appropriate visualisation option.
class_iofactor	The class_iofactor specifies as a fraction, the position where relations connect to the edge of an entity. Relation classes that have an IO factor that is not specified, or is -1 will be assigned a default internal iofactor, that ensures that connection points for distinct relation classes occur at distinct points that suitably separate these connection points.
class_hierarchy	The class_hierarchy specifies as an integer, the logical number of this relation class, when it is used to form the landscape hierarchy of entities, contained within entities. This number is used to index into the arrays of positioning information.
class_iscontains	The class_iscontains attribute specifies as an integer value the position of this relation class within those relation classes to be used to impose a contains heirarchy on entities, with 0 being first, and -1 being not used for this purpose. Legacy values of true and false are treated as 0 and -1 respectively. This parameter across relation classes establishes the desired contains hierarchy when the landscape is first opened.
Entity class attributes
class_style	The class_style attribute specifies the shape of an entity class and all subclasses that choose to inherit that same shape. Instantiations of a class always inherit there style from their class. Class style is an integer and can have the following values: 3D box - a box with raised borders; 2D box - a plain rectangle; File - a rectangle with top right corner folded; Disk - a stylized depiction of a cylinder; Folder - an image of a folder; Source object - an ellipse; Class - a rectangle with rounded corners; Group - a transparent raised box; Labelled group - a transparent box with the label displayed on the top border; Directed Triangle - a triangle; Rhombus - a rhombus on its side; Directed Trapezoid - a trapezoid; Triangle; Four-sided diamond; Pentagon - five-sided polygon; Hexagon - six-sided polygon; Octagon - eight-sided polygon; Decahedron - 10-sided polygon; 12-sided polygon; 14-sided polygon; 16-sided polygon; 18-sided polygon; Dodecahedron - 20-sided polygon; Paper - a rectangle with a curved bottom edge; Sunken box - a 3D box with sunken borders; Invisible box - a completely invisible box with only the label showing. You can download the landscape which showcases all available class styles here.
class_angle	This attribute allows you to specify how much the initial shape of an object is to be rotated. The rotation angle is measured in degrees; the rotation is always performed in the clockwise direction. Regular shapes explicitly named as being n-sided, can be rotated by any angle. Not all shapes respond to rotation in the same way. Some shapes (called directed shapes) can only be rotated by a multiple of 90 degrees. If for a class that has a directed shape you specify a rotation angle that is not a multiple of 90 degrees, it will be automatically rounded to the closest multiple. The directed shapes are: Directed triangle; Directed rhombus; Directed trapezoid. Some shapes can not be rotated at all; generally, these are in the shape of rectangles with advanced features (e.g. 3d boxes or folders). These can not be rotated because rotation will cause them to be rendered outside of their clipping area. Here is the full list of class styles that do not respond to rotation: 3D box; 2D box; File; Disk; Folder; Source object; Class; Group; Labelled group; Paper; Sunken Box. Specifying a class angle for these class styles is not an error; the attribute is simply ignored.
class_image	This integer attribute allows you to associate an extra image with a class. That image will then be drawn on (or around, depending on the image you choose) every entity of that class. The available images are: 0x01 Stick man (drawn inside the entity); 0x02 Oval; 0x04 Rectangular frame; 0x08 Rectangular frame with rounded corners; 0x10 X-mark (drawn inside the entity). It is possible to associate more than one image with a class; to do that, simply add the values for all the images you want to be associated with the class. For example, to get a class to have both a rectangular frame and an X-mark, you would use the class_image value of 4+16=20: class_image = 20
class_icon	This string attribute allows you to specific the name of an image file, that will be used to establish an icon for the class. The icon will be shown when instances of this class are closed, provided that the visualisation options specifies that icons are to be shown, and the specified image file can indeed be read. Results are unpredictable if the specified image file does not contain a valid image in a recognised image format such as jpg or gif. Relative path names are computed relative to the location of the executable code. Entities represented by icons, are presume to have the same basic shape as that specified by the class_style. A rectangular class_style is recommended, if you wish edges to terminate at the outer rectangular boundary of the icon. However, if the icon is specifically created to conform to some other recognised class_style, then edges will naturally also connect to such icons at the position determined by that class style.
opencolor	This attribute controls the color of an entity when it is open. In such a state any child entities appearing under such an entity become visible. This attribute value is specified as for color. If no open color is set then an attempt is made to choose a suitable default color for the open entity based on its current visual depth within the heirarchy.
Relation attributes
style	This attribute can be used to override the class_style associated with a specific relation.
label	This attribute can be used to associate and show a label with a relation. The decision as to whether to show edge labels is determined by visualisation options. The label can be set to any string, although it is advisable to keep labels relatively brief to avoid display problems. If the label attribute is not present, the corresponding relation has no label.
rlabel	This attribute can be used to associate and show a reversed label with a relation, when the direction of that relation is reversed. The decision as to whether to show edge labels is determined by visualisation options. The reversed label can be set to any string, although it is advisable to keep reversed labels relatively brief to avoid display problems. If the reversed label attribute is not present, the corresponding relation has no reversed label.
Entity attributes
label	The label attribute sets the label - the text that is displayed on the entity. The label can be set to any string, although it is advisable to keep labels relatively brief to avoid display problems. If the label attribute is not present, the entity's internal name is displayed as the label instead.
title	This attribute can be used to provide a title to the text specified in the description attribute. The text in the title will appear in the top left corner of LSEdit's status bar, above the description pane. This attribute is wholly independent of the description attribute, however, and can be used on its own. The title can be set to any string; it is advisable, however, to limit titles to strings that can fit into the LSEdit's status bar.
description	The description parameter is intended for storing an extended, multi-line description of an entity. The description is displayed in LSEdit's top status bar whenever the entity is selected.
opencolor	This attributes overrides the open color associated with the entity class if present.
fontdelta	Fontdelta stores the increment (or decrement) of the entity's label font size. Possible values for this attribute are positive or negative integers. Every entity starts out with the default font size (unless otherwise specified in the schema section of the landscape). This font size is considered to be the base size, or fontdelta of zero. To determine the size of the font that will be used to draw the label, the fontdelta value is added to the size of the base font. Thus, if fontdelta is set to 8, the label of the entity will be drawn with a font size that is 8 points bigger than the base font size.
Entity layout attributes
xrel	This attribute is used to specify the X (horizontal) coordinate of an entity, or more specifically, its top left corner. Valid values for this attribute are double precision values between 0.0 and 1.0 (including decimal point), or short integer values (containing no decimal point). The horizontal position of any entity is a relative to the width of the parent entity. For the purposes of layout, if the left border of the parent entity is assumed to have the X coordinate of 0.0, and right border - the coordinate of 1.0; the value of xrel will determine exactly where between the two borders the entity is positioned. If a short integer value is specified a value between -Short.MAX_VALUE and Short.MAX_VALUE is linearly mapped to the corresponding 0.0 to 1.0 range. Short.MIN_VALUE represents an undefined value. Internally within LSEdit short values are used because these provide good balanced granuarity (in discrete steps of 1/(2^16-1) of the actual landscape size), even when landscapes are zoomed; involve considerably less memory overheads; are computationally more efficient to work with; and are more efficiently and accurately represented in output TA files emitted by LSEdit. LSEdit will attempt to use the currently preferred layout algorithm to determine suitable values for an entity when it lacks or has an invalid xrel value. While this value may be directly edited as an attribute, it is typically changed by dragging entities around. Relative coordinates are used in preference to absolute coordinates since these are more natural when the shape of containers change, and because there is no constraint on how deeply a layout may be nested before problems start arising with the precision of the internal representation of the coordinate values. The four positioning attributes xrel, yrel, widthrel, and heightrel may also be assigned lists of double precision values. Such lists are formed whenever multiple hierarchies using different relation classes are viewed using LSEdit. Each such component in the resulting list corresponds to a specific relation class, permitting layout information to be preserved, not simply for the contains relation class (the default class used to establish a landscape hierarchy) but for all relation classes used to determine the various landscape hierarchies.
yrel	This attribute is used to specify the Y (vertical) coordinate of an entity, or more specifically, its top left corner, just as the xrel specifies its horizontal position. The vertical position of any entity is relative to the height of the parent entity. For the purposes of layout, the top border of the parent entity is assumed to have the Y coordinate of 0.0, and bottom border - the coordinate of 1.0; the value of the xrel and yrel will determine exactly where between the two borders the entities top left corner is when shown to be positioned.
widthrel	This attribute is used to specify the width of the entity being drawn. Valid values for this attribute are numbers between 0.0 and 1.0. The width is a relative to the width of the parent entity. The widthrel value will be used to calculate the width of the box by multiplying widthrel by the physical width of the parent entity. For example, an entity having a widthrel of 0.5 will be shown half as wide as the box it is contained in.
heightrel	This attribute is used to specify the height of the entity being drawn. Valid values for this attribute are numbers between 0.0 and 1.0. The height is a relative to the height of the parent entity. The heightrel value will be used to calculate the height of the box by multiplying heightrel by the height of the parent entity. For example, an entity having a heightrel of 0.5 will be shown half as tall as the box it is contained in.
Entity elision attributes
elision	The elision parameter allows you to specify which types of relations going to the entity should be hidden (see also the outelision attribute). The parameter is assigned a list containing the names of relations which should not be shown, for example: elision = (useVariable callFunction) This means that if there are arrows of type useVariable or callFunction going to the entity in question, they will be hidden.
outelision	The outelision parameter allows you to specify which types of relations going from the entity should be hidden (see also the elision attribute). The parameter is assigned a list containing the names of relations which should not be shown, for example: outelision = (useVariable callFunction) This means that if there are arrows of type useVariable or callFunction going from the entity in question, they will be hidden.
clientelision	The clientelision parameter allows you to specify which types of relations going from outside to inside an entity should be hidden (see also the supplierelision attribute). The parameter is assigned a list containing the names of relations which should not be shown, when entering the corresponding entity. For example: clientelision = (useVariable callFunction) This means that if there are arrows of type useVariable or callFunction going into the entity in question, they will be hidden.
supplierelision	The supplierelision parameter allows you to specify which types of relations going from inside to outside an entity should be hidden (see also the clientelision attribute). The parameter is assigned a list containing the names of relations which should not be shown, when exiting from the corresponding entity. For example: supplierelision = (useVariable callFunction) This means that if there are arrows of type useVariable or callFunction going from inside the entity in question to outside this entity, they will be hidden.
internalelision	The internalelision parameter allows you to specify which types of relations going from inside to inside an entity should be hidden (see also the clientelision attribute). The parameter is assigned a list containing the names of relations which should not be shown, when entirely contained within the corresponding entity. For example: internalelision = (useVariable callFunction) This means that if there are arrows of type useVariable or callFunction strictly inside the entity in question, they will be hidden.
open	The open parameter contains a list of relation class names which when used as the containment edge imply that the corresponding entity is to be treated as open. That is, edges out of this entity, when belonging to the specified containment relation class, are to be treated as visible. Counter to all of the other elision parameters, this elision parameter, is specified when edges should be made visible, rather than when they should be made invisible. This is because by default it is desirable that landscapes are initially presented with all entities closed, so as to minimise draw and display overheads. For example: open = (contain callFunction) This means that when the containment relation class is contain or callFunction the entity having this parameter is to be displayed as open, thus showing any children contained within it. When any other relation class forms the containment hierarchy this entity is to be displayed as a closed entity.
Entity edge point attributes
inpoints	Edge point attributes are specified as a list of triples, with each triple consisting of a relation class name, a relative x cordinate and a relative y coordinate. Such edge point attributes override the default position (internally assigned or externally specified in the relation classes class_iofactor attribute) where edges corresponding to the indicated relation class connect to entities. The inpoints attribute overrides the point where relations leaving/arriving at the top of an entity are to begin/end.
outpoints	The outpoints attribute overrides the point where relations leaving/arriving at the bottom of an entity are to begin/end.
leftpoints	The leftpoints attribute overrides the point where relations leaving/arriving at the left side of an entity are to begin/end.
rightpoints	The rightpoints attribute overrides the point where relations leaving/arriving at the right side of an entity are to begin/end.
Deprecated attributes
color deprecated	The deprecated method (as of LSEdit version 7.0.49) of specifying color components as double precision values in the range 0.0 to 1.0 is still supported but internally merely multiplies the provided double precision numbers by 255 and then assigns the color component the resulting integer value. As a special case note that 1 is interpreted as the color component value 1, while 1.0 is interpreted as the color component value 255. Saved landscapes now always express color components as integers in the range 0 to 255. This is much cleaner and far more accurate than emitting potentially very lengthy double precision numbers.
x deprecated	This attribute was used to specify the X (horizontal) coordinate of an entity. This attribute is now deprecated, because LSEdit has been converted to relative entity dimensions. This attribute has been superseded by xrel and should no longer be used. LSEdit will automatically convert all landscapes from absolute to relative dimensions; new landscapes should be built using relative dimensions only.
y deprecated	This attribute was used to specify the Y (vertical) coordinate of an entity. This attribute is now deprecated, because LSEdit has been converted to relative entity dimensions. This attribute has been superseded by yrel and should no longer be used. LSEdit will automatically convert all landscapes from absolute to relative dimensions; new landscapes should be built using relative dimensions only.
width deprecated	This attribute was used to specify the width of an entity. This attribute is now deprecated, because LSEdit has been converted to relative entity dimensions. The width, therefore, has been superseded by widthrel. LSEdit will automatically convert all landscapes from absolute to relative dimensions; new landscapes should be built using relative dimensions only.
height deprecated	This attribute was used to specify the height of an entity. This attribute is now deprecated, because LSEdit has been converted to relative entity dimensions. The height, therefore, has been superseded by heightrel. LSEdit will automatically convert all landscapes from absolute to relative dimensions; new landscapes should be built using relative dimensions only.

[top]

The $ROOT entity

The $ROOT entity is special. It does not have to be declared (and in fact cannot be declared), it is automatically assigned to class $ENTITY, and it is assumed to exist even if it is omitted from the landscape. LSEdit places $ROOT as the top of the containment hierarchy, and uses its attributes to store information that is not specific to any entity, but rather describes the landscape in general.

The $ROOT entity and all its attributes are optional. A landscape does not have to contain it to be valid - LSEdit will simply revert to default values while displaying it. However, you may want to use the $ROOT entity to gain extra control over how your landscape is presented.

$ROOT should only be mentioned in the attribute section of a landscape (TUPLE ATTRIBUTE :), where its attributes can influence the overall look and feel of the landscape. The table below lists available attributes, their possible values and their impact on the landscape.

$ROOT Attributes
Standard attributes	$ROOT is a normal entity in this respect. It has all the attributes an ordinary entity would have. However, changing most standard attributes does not have any impact on the landscape. For example, the dimensions and location of an entity are only meaningful in the context of the parent box, and $ROOT does not have one, being the root of the entire landscape; location and size coordinates are therefore not meaningful. Other attributes, like colors and labels, have the same effect on $ROOT as they do on any other entity. $ROOT's special attributes are the main reasons for its existence.
version	This attribute merely indicates the version of lsedit in use when this landscape was last saved.
topclients	This attributes controls whether clients (entities that link to the entities currently displayed in the main display area, but contained in other areas of a landscape) are displayed on the top of the landscape or on the bottom. The default setting is to display the clients on the top and the suppliers (the inverse of clients) on the bottom. This setting can be used to flip the display. Valid values for this settings are true and false; the default value is true.
edgemode	This attribute controls how edges are displayed in LSEdit. Possible values for this attribute range from 0 to 2; their meanings are: Inflection point edge. This option forces the edges going to and from clients and suppliers to converge on a central point at the border of the landscape before going to their destinations. This option can be useful to cut down on the clutter in a large landscape. Top/bottom edge. When this option is selected, all edges going from an entity start at its bottom border, and all edges going to the box end at its top border. This eliminates the need for arrowheads and makes the relationships more apparent, at the cost of adding clutter to large diagrams. Direct edge. The inverse of option 1, this option lets the edges take the most direct route between its start and destination. This is the default option.
navlink	The entity to become the root of the visual landscape, when this landscape is opened. ...
wantcardinals	This option allows you to hide or display cardinals. Cardinals are indicators that show the cardinality of relations going to an entity. Valid values for this attribute are true and false.
wantoutcardinals	This option allows you to hide or display out edge cardinals. Such cardinals are indicators that show the cardinality of relations going from an entity. Valid values for this attribute are true and false.
wantclients	This option allows you to hide or display clients - entities that link to entities currently displayed, but not contained in the same entity. This option is on by default. Valid values for this attribute are true and false.
wantsuppliers	This option allows you to hide or display suppliers - entities that are linked to by entities currently displayed, but not contained in the same entity. This option is on by default. Valid values for this attribute are true and false.
font[?]	These attributes describe the initial fonts to be used when the diagram is loaded.
diagram:?	These attributes describe the diagram options to be used when the diagram is loaded.
option:?	These attributes describe landscape options to be used when the diagram is loaded.
arrow:?	These attributes describe visualisation options to be used when the diagram is loaded.
view_?:	These attributes each contain an encoded description of a view to be shown within LSEdit.

[top]

Files without schema and layout

To achieve the best results in presentation and clarity of a landscape, both a schema section and layout information must be included in a landscape. They are not mandatory, however - given a file with no schema, LSEdit will revert to a default schema; similarly, when given a landscape without layout information, LSEdit will use its internal layout routines to lay out the landscape. Although sometimes lacking the clarity and features of more advanced landscapes, these landscapes with auto-schemas and auto-layouts can nevertheless be immensely useful.

Auto-schemas and auto-layouts are at their best when there is a need to quickly visualize a relatively small graph without expending a lot of effort on layout. In these cases, it is best to let LSEdit do the layout work, and forgo the advanced layout features for the speed and ease of the automated solution. The following paragraphs describe how LSEdit handles landscapes without a schema and/or layout information.

Landscapes without a layout. A landscape without a layout is a landscape in which some or all entities do not have set values for their positioning attributes (xrel, yrel, heightrel, widthrel). When encountering a landscape like this, LSEdit uses its built-in layout routine (the same one that is available from the Layout menu) to lay out the landscape before displaying it.

Landscapes without a schema. A landscape without a schema has an empty schema section; this means that LSEdit does not know what kind of entities and can exist, and what relations can link what entities. When faced with such a landscape, LSEdit makes the following assumptions:

• All entities are of type $ENTITY;
• All relations except contain are of type $RELATION;
• Any entity can contain any other entity;
• Any relation can link any two entities;

Internally, LSEdit stores the schema-less landscape as if it conformed to the above schema. This means that if the landscape is saved, it will be saved as a landscape with the above schema: the corresponding SCHEME TUPE : section will be inserted, all entities will be declared as being of type $ENTITY, and all relations except contain will be amalgamated into a single relation called $RELATION. It is wise to keep these facts in mind when working with, and saving, schema-less landscapes: without due care, distinction between relations can easily be lost.

The contain relation is, as usual, treated specially, in that it is expected to represent containment information, and be a tree or a forest.

Unlike layout information, where it is possible to include it for some entities and omit it for others, schema specification is an all-or-nothing affair. Either the landscape has no schema, in which case the default one is used, or the landscape must have a complete schema that describes all relation and entity classes and declares all its entities. "Schema completion" is not supported.

It is permissible for a landscape to have neither the schema nor the layout information. In this case LSEdit will revert to the default schema and apply its layout algorithm as needed.

[top]

Example

A landscape that uses most of the features described above can be found here. The file is commented for greater clarity.