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:

Concept	Description
DataType	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: Person Name Date_of_birth Date Mobil_phone_number SMS Email_address EMail Home_page URL (the first PropertyType "Name" has the default DataType ShortText)
Cardinality	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). Person Name Phone_numbers SMS ZeroToMany Yearly_income Integer Optional Car_ownership RelationMany Car Model 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.
Simplification	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: Person First_name Last_name 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.
AccessType	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.
Role	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.
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 Name Phone_number Rule ReadEveryone ChangeAdministrator Name Events ReadAnonymous ChangeOwner Name Date Date Money_transfer Administrator Amount 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) Example: Money_transfer ReadEveryone Change(42) Amount Date Date Only the entity with PropertyID 42 may Change (Create, Update or Delete) a Money_transfer.
GivingRole	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 Name Family_membersship RelationMany GivingOwner Person ReadEveryone ChangeOwner First_name Last_name 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_group Name Administrator_person RelationMany GivingAdministrator History Log Person First_name Last_name 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.)
IdentificationUsefulness	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. Example: Person First_name Essential Last_name Essential Date_of_birth Education
SubName	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. Example: Person / Persons First_name Last_name Employer \| Is_employed_by \| Employment / Person_org RelationOne Organisation / Organisations Name 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 First_name Last_name Employer \| Person_org RelationOne Organisation / Organisations Name Employees \| Person_org RelationMany
Function	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 Example: 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 Example: 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.
FunctionCategory	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.
Operator	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.
Classification	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