panSL main page

panSL language reference page

Looking for a tutorial to panSL? Try an introduction to panSL with step-by-step examples or go direct to some samples.

These pages contain a summary of various elements of panSL (pan Schema Language) meant for reference purposes.

This information should be useful both for the creation of online web-databases through MyLittleDatabase, and for modelling and exploring automatic generation of source code through AgoRapide.

The main concepts are DataType , Cardinality , Simplification , AccessType , Role , AccessRole , GivingRole , IdentificationUsefulness , SubName , Function , FunctionCategory , Operator , Classification . A summary of each concept is given below:



Describes what kind a data a Property of a given PropertyType may contain.

ShortText is the default DataType. Properties of this datatype may contain any kind of text or numbers.

Example of how some of the DataTypes, Date, SMS, EMail and URL, may be used:

   Date_of_birth       Date
   Mobil_phone_number  SMS
   Email_address       EMail
   Home_page           URL

(the first PropertyType "Name" has the default DataType ShortText)


Describes cardinality for a given PropertyType's relation to another PropertyType, such as Optional (ZeroToOne), Obligatory (ExactOne), ZeroToMany and OneToMany.

The example below shows some examples of Cardinality, a Person may have ZeroToMany phone numbers, is is Optional to specify Yearly_income, he / she may own
many cars (RelationMany) and a car may only be owned by one person (RelationOne).

   Phone_numbers   SMS ZeroToMany
   Yearly_income   Integer Optional
   Car_ownership   RelationMany

   Car_ownership   RelationOne

In the example RelationMany is a Simplification of DataType Relation and Cardinality ZeroToMany and
RelationOne is a Simplification of DataType Relation and Cardinality Obligatory.


panSL-schemas are typically shown in simplified form.

Common combinations of DataType, Cardinality, HistoryType and AccessRole may be simplified.

By simplifying the schema it becomes easier to read and faster to develop (less typing is required).

A simplified schema may look like:

   History     Log

The same schema in complex format, that is without any Simplifications, would look like:

Person         Heading CreateAnonymous UpdateAnonymous DeleteAnonymous ReadAnonymous
   First_name  ShortText Obligatory
   Last_name   ShortText Obligatory
   History     History ZeroToManyReverseAdd Create Update Delete

Note how many of the specifier keywords were just reduced to Nothing in the simplified version.


Describes operations against the database.

Can be used in two different circumstances:

1) Used in combination with Role to describe Role needed to perform a certain AccessType. The combination of AccessType and Role is called AccessRole.

2) Describing what kind of operations that should be logged when specifying a PropertyType with DataType History.
The term HistoryType is used instead of AccessType in such cases.

Note that the MyLittleDatabase Implementation of panSL also uses the concepts Login and Message in order to log
log-in events and sending of messages. These are however automatically assumed, and not part of panSL at the moment.


Describes different roles relevant in connection with AccessType.

The roles recognized, in increasing order of restrictions regarding access,
are Anonymous, Everyone, Owner, Administrator, Nobody

Role is often specified together with an AccessType like Create, Read, Update, Delete in
a single keyword. Such a combination is called an AccessRole.


With AccessRole is meant what kind of Role (Anonymous, Everyone, Owner and Administrator)
the user of an ApplicationImplementation needs in order to perform an operation of a given AccessType (Create, Read, Update or Delete).

An AccessRole-keyword is thus a combination of AccessType and Role.

Note that common combinations are simplified. If the same Role is needed for every kind of Access then only the Role needs to be indicated.
For instance, Administrator signifies CreateAdministrator ReadAdministrator UpdateAdministrator DeleteAdministrator.
The common combination for Create, Update and Delete is simplified to Change + Role, for instance ChangeEveryone signifies
CreateEveryone, UpdateEveryone, DeleteEveryone (Read-Access in such a case would normally be ReadAnonymous).

Example of use:

Person           ReadEveryone ChangeOwner

Rule             ReadEveryone ChangeAdministrator

Events           ReadAnonymous ChangeOwner
   Date          Date

Money_transfer   Administrator
   Date          Date

The example gives various examples of how access may be specified.

AccessRole may also be specified as Role + PropertyID. In this case the user of an ApplicationImplementation needs to either
A) impersonate the given Property, or to
B) have a relationsship to it (for instance the Property could be a group "Account_department" with users as members)


Money_transfer   ReadEveryone Change(42)
   Date          Date

Only the entity with PropertyID 42 may Change (Create, Update or Delete) a Money_transfer.


May be specified for PropertyTypes of DataType Relation, for two purposes:

A) To give the related entity role as Owner of the given entity.
B) To give the related entity role as Administrator (of the whole database).

Example A), giving a Person-entity role as Owner of a Family-entity:

Family                 ReadEveryone ChangeOwner
   Family_membersship  RelationMany GivingOwner
Person                 ReadEveryone ChangeOwner
   Family_membersship  RelationOne
   Mobil_phone         SMS

It is not possible to log-in as a Family. Therefore Person-entities related to a given Family is given Role as Owner.
This makes it possible for a Person to edit his own Family.
(In this example log-in is performed by requesting a one-time password as SMS-message to a given mobil-phone number.)

Example B), giving a Person-entity role as Administrator (of the whole database):

   Administrator_person   RelationMany GivingAdministrator
   History                Log
   Administrator_person   RelationOne
   Username               Username
   Password               Password

By creating an Administrator_group and relating it to a Person-entity the Person-entity would be granted Administrator-rights after log-in.
(In this example log-in is performed in the traditional manner by Username and Password.)


Describes what importance should be given to a PropertyType when making short descriptions of entities.

A typical example is when making a quick list of persons or when linking to a person. Then often First_name and Last_name
are the Essential characteristics which we would like to display.

The various levels, in order of increasing importance, are: Additional, Useful, Essential.


   First_name    Essential
   Last_name     Essential


It is often necessary to specify different names for a PropertyType.

Two conventions are supported in panSL:

A) SingularName / PluralName
The example below uses "Person" / "Persons" and "Organisation" / "Organisations"

B) UIName | ModelName | ERDiagramRole | UserfriendlyName / IdentificatorName
The example below shows different aspects of an Employment-relationship.


Person / Persons
   Employer | Is_employed_by | Employment / Person_org   RelationOne
Organisation / Organisations
   Employees | Employs | Employment / Person_org         RelationMany

Not every SubName needs to be specified. If a particular SubName within the PropertyName is not given
the name of its closest "right-hand neighbour" is used instead. As a minimum the IdentificatorName must be specified.
In other words, a SubName propagate from right to left until a new SubName is specified.

If for instance ER-modelling is not desired or important, the example above could have been written as:

Person / Persons
   Employer | Person_org       RelationOne
Organisation / Organisations
   Employees | Person_org      RelationMany


Functions may be used with PropertyTypes of DataType Formula.

This page lists all functions. You may also look up functions by FunctionCategory.

There are two possible styles for using functions:

1) Traditional spreadsheet style with function-name followed by arguments in parantheses


Year_of_birth = Year(Date_of_birth)
Left_part_of_name = Left(Name,5)
Length_of_name = Length(Name)

2) Object-oriented style with the "main" argument expressed first, followed by a full stop and then the function-name followed by the remaining arguments (if any) in parantheses


Year_of_birth = Date_of_birth.Year()
Left_part_of_name = Name.Left(5)
Length_of_name = Name.Length()

The parantheses may be omitted if there are no arguments remaining. Two of the example above could thus be written as:

Year_of_birth = Date_of_birth.Year
Length_of_name = Name.Length

The object-oriented style is usually preferred when functions are arguments to new functions (that is when you are nesting functions within functions).
For instance, Name.Left(10).Upper is usually easier to read than Upper(Left(Name,10))

The styles may be mixed, for instance like Left(Name,10).Upper

Note that identifiers (name of PropertyTypes) can also be referred to in formulas in PascalCase.
That is Date_of_birth can be referred to like DateOfBirth if preferred.


Categories of panSL Functions.

Note that this is only a first subset of what are deemed necessary functions. More functions are expected to be added in the near future.


Operators are used in Formulas.

Note: As of April 2012 evaluation of Formulas is only at alpha-stage (still under development) in the panSL Implementations AgoRapide and MyLittleDatabase.
Operators are evaluated from left to right only.
Operator precedence is not supported at the moment, that is
2 + 3 * 4
evaluates to 20 not 14 (in other words multiplication and division is not done before addition and subtraction)
Use parantheses to correct this, that is use
2 + (3 * 4)
if a result of 14 is desired.


Describes some common terms used when describing panSL and how they should be understood.

The keywords shown for Classification are not part of panSL in itself.

Complete dictionary of all keywords and some concepts

Last updated 2012-05-02