SDML has changed extensively since release 2.6. Old models will need
extensive modifications for them to work in 3.0. Also, some of the
features of SDML 2.6 have not yet been reimplemented in 3.0.
Therefore, you are recommended to continue with 2.6 for the time
being, unless you need to use the new features of 3.0.

There will be multiple sub-releases of 3.0 (3.0a, 3.0b, etc) until
all 2.6's features have been reimplemented. For details of the
features that have not yet been reimplemented, click on the
appropriate sub-release in the release browser.

The main new features of SDML 3.0 are as follows:

	a) A "building block" approach is used, to provide much
greater flexibility in the structuring of models. Modellers can
define composite agents which contain sub-agents, those agents can
contain further sub-agents, etc.

	b) Modellers also have much greater flexibility in handling
time. Multiple time levels can be defined, with the modeller
specifying the agents for which each time level is applicable. By
default, times start at 0 and increment by 1, but the modeller can
override these. Real numbers can be used for times if required, and
increments between one time period and the next may vary - this makes
SDML suitable for discrete event simulation. 

	c) There is a powerful mechanism to define instances of types
(which are now known as 'objects' rather than 'symbols'). Every agent
type has its own object table, in which instances of various (other)
types can be defined. If there are multiple instances of the agent
type, then each such agent contains local instances as defined in
that object table. Every object has a "path" as well as a name, which
can be used to uniquely identify the object (if required). Instances
defined in the simulation (using "generatedInstance" and the new
"namedInstance" primitive) are stored in a different object table,
associated with the simulation.

	d) A more powerful inheritance mechanism is implemented,
whereby agent types specify the types of their containers (using
"container type constraints"), and definitions (of clauses and
objects) are inherited from container types, and container types of
container types, etc.

	e) A special agent known as the "universe" is provided, which
is always the outermost agent. Definitions in its type
("UniversalAgent") are inherited by all agent types.

	f) Agents can have three kinds of rulebase - "content",
"initial" and "final". An initial rulebase is fired at the beginning
of the initial time at a specified time level and the final rulebase
is fired at the end of the final time at the time level. Agent types
can define multiple initial and final rulebases, corresponding to
different time levels. Agent types also contain content rulebases,
which are inherited by the content rulebases of specific agents.

	g) Agents have hierarchies of sub-databases corresponding to
different time levels. For example, for an agent that is simulated
over dates and iterations, it has a permanent database (time level
"eternity"), sub-databases containing information that is true
throughout specific dates (time level "date"), and each of these
sub-databases has further sub-databases for information that is true
at specific iterations (time level "iteration").

	h) Meta-level rulebases are represented as content rulebases
of "meta-agents". Meta-agents have access to the content rulebases of
their containers (consequently permanent content rulebases have
hierarchies of sub-rulebases corresponding to different time levels,
as with databases). If meta-agents are contained in composite agents,
then they also have access to their container's other sub-agents.
Meta-agents can be "meta-meta-agents" by putting them within other
meta-agents.

	i) There can be more than one clause definition for the same
predicate (formerly known as a "keyword") accessible within the same
agent type. Syntax diagrams are used to determine which clause
definition(s) to use when evaluating or performing a particular
clause. All clause definitions defined in any of its supertypes are
inherited; these are at the "current" level and access the agent's
own database. However, clause definitions at the "container" level
are only inherited (from the container type and its supertypes) if
the agent type has no current definitions for the predicate; such
definitions access the container's database. "Outer" and "universal"
level definitions are inherited in a similar manner.

	j) Backward chaining clause definitions have their own
mini-rulebases. These rules are fired whenever a clause that adheres
to the definition's syntax is evaluated. Other backward chaining
rules can also be fired by evaluating such clauses - these must be
placed in or inherited by the agent's content rulebase.

	k) Clause definitions have access permissions, which specify
to what extent they can be used in antecedents and consequents of
rules (these access permissions are known as "readability" and
"writeability" respectively). They can be defined as "public"
(accessible by any agent), "internal" (accessible by the current
agent, its sub-agents, their sub-agents, etc) or "private"
(accessible only within the current agent). Writeability "none" is
useful for primitives that can only be used in antecedents, and for
backward chaining predicates for which no extra rules can be supplied
in the content rulebase.

	l) Clause definitions and rules (except for those in
mini-rulebases associated with clause definitions) are arranged in
"categories", to facilitate easier browsing.

	m) Groups and types can be given comments.

	n) Group write permissions are extended to enable modellers
to specify that only they can make changes to a particular group.
Changing a group conceptually modifies its sub-groups (by switching
to a new version of the super-group) so the current user can only
modify a group if he/she also has write permission to all sub-groups
in the SDML image.

Other changes to SDML include:

	1) An "operation list" is provided instead of the "undo
list". There is a single operation list for the SDML image (instead
of different ones for each project). Operations are output to an
operations file as soon as they are performed, enabling the user to
recover operations from this file if SDML is exited without saving.

	2) There are many changes to the modeller's interface,
including new redesigned browsers (many of which combine facilities
that previously required multiple separate browsers). Most browsers
now "grey out" menu options that are temporarily unavailable, rather
than removing them from the menus.

	3) All definitions that the modeller uses to describe a
model, including rulebases, clause definitions and objects, are
placed within types in simulation groups. Therefore, groups contain
all information about a model, so a single group file can be used
instead of separate group and model files. Different groups must be
filed out as separate files (with the extension ".sdm").

	4) Groups no longer contain clause definitions - instead such
definitions must be placed in an appropriate type, e.g.
"UniversalAgent", "Agent" or the type of the model. Group rulebases
are no longer provided either - backward chaining rules that were
previously placed in such rulebases must be moved to other rulebases,
e.g. mini-rulebases associated with appropriate clause definitions,
or the content rulebase of type "Agent".

	5) All type names have changed, to start with a capital
letter. The further changes have also been made:

		variableFreeTerm -> GroundTerm

		variableFreeClause -> GroundClause

		variableFreeList -> GroundList

		atom -> AtomicTerm

		symbol -> Object

	6) The sector model browser, group "sectorModel", types
"sector" and "market", and clause definitions and rules within it
(e.g. for "valueOf"), are no longer provided.

	7) Primitive "generatedName" is no longer provided,
"generatedInstance" with type "RuleName" should be used instead.

	8) The following predicates (aka keywords) are renamed (some
with different syntax):

		finished -> final

		age, lag -> lag

		symbolString -> objectName

	9) The following predicates have different syntax: parsed,
printed, generatedInstance, excelTable, rule

	10) The primitive "self" (previously known as "agentName") is
obsolete - instead the special object "self" is used which always
corresponds to the current agent.

	11) New types are provided for different kinds of agent, as
well as "NumericFormat" (for use in primitive "printed") and
"Functor" (all clauses with at least one argument must be a functor).