fts data model

FTS data model

FTS (Feldman Technology System) - the only No programming IT System in the World
You want to know… Nobody can help you but you yourself… The only way to know is to build some system making the knowledge… Nobody can build the system for you but you yourself…But somebody can help you by making some tools for you. You are not a programmer and never would be. Your only dream is not to learn more than you really need to learn.You know the real world. What is the minimal set of notions to solve your problem?
What we intend to do is to give you the set and explain why the set is minimal and cannot be reduced or improved in any way. Take in account that there is at least one real system built with tools below. But we want to delay implementation details as long as possible.

1 Ideas
1.1 Information must be clean
By the way it means that your information must b cut into small pieces. Every piece must be in somebody's responsibility zone. Responsible person could have a boss that is not less responsible than he/she is. The chain must end on the person called SYSADMIN. SYSADMIN is absolutely responsible person. No piece of information is in two or more zones simultaneously. No person has two or more bosses simultaneously.
Such system of responsibility can guarantee the information to be clean as much as it could be.

1.2 Responsibility must be distributed.
SYSADMIN cannot work alone - it is impossible. Another users must take some part of responsibility on the system. Some users may delegate some part of their responsibility by creating another users. If USER ONE created USER TWO it means that all activity of TWO is visible and controllable by ONE. ONE could control TWO. But if TWO is known as qualified and responsible user ONE will not control every step of TWO. ONE will delegate the part of their obligations to TWO. In some day ONE permit TWO to create user named THREE an so on.
Responsibility would be distributed as soon as it could be.

1.3 Access must be controllable.
The most important moment in the life of the system is object creation. Who created the object is the owner of the object and is responsible on the object. There is some list of TYPES. Every object could be created for one (an only one) type of the list. Some types allow creation by any user. Some types demand license to be created. Some types are included in another types. (Type ma be included in one type only). Included type cannot be licensed. User can create object of type included only if he/she is owner of some object of type including the type included. And included object would be included in the object of type including. Some type are declared as recursive. If object of such type is created new object of the same type could be crated under it.
SYSADMIN can create any license. SYSADMIN can move the license to any user. The user can use the license to create object of his/her own. The user can give the license to somebody else. The user can copy license and give the copy to somebody else. User is type to be licensed. You can change type to be licensed inside the license but you cannot jump out from the set of types really licensed for the moment for you and your dependants (if you are not SYSADMIN)

1.4 First Summary.
So we have
· objects,
· types,
· users (they are objects),
· licenses (they are objects),
· users and licenses are types
· included-including types and objects,
· SYADMIN,
· tree of objects with SYSADMIN as root

1.5 Objects, ID, parent
There are "real objects" or RO in real world and there are pieces of information as "information objects" or IO. When IO appears in system in the first time it has at least two things 1)existence and 2)ownership. For us it means that every object has 1)unique system number (ID) and 2)ID of parent. Finally, the owner of an object is some user. However, if the object A is included in another object B we take B as parent for B. If the object A is created by license B the parent of A is B.

1.6 Types, complex types, inheritance chain
Whenever the object is created it has one and only one type. However, in real world one object could change its type but keep itself. More than that, an object sometimes wants to have many types or "set of types" with one type in the set marked as "center". Such phenomena we call "complex type". Axioms as follows will be kept
· Every licensed type object (LTO) has complex type. Object created without license has "simple type" as one value of the types' list.
· All licensed types make a tree with root OBJECT. The tree is "inheritance tree". The path from any node of the tree to OBJECT is "inheritance chain". When LTO is created under type A its complex type consists of type set "inheritance chain of A" and type center A.
· We can change type center inside type set. We can change the type set. We can add to the type set any node we can reach from type center in the tree not passing through OBJECT. When we add some node B to the type set every node on the "inheritance chain of B" is added automatically. So the type set is a subtree. We cannot reduce the subtree cutting off the inner node of the subtree but only cutting off the edge node.

1.7 Inheritance, data elements, primitive data types, files, keys.
When real object became information object it means that we know something about it. Our knowledge consists of elements. Elements are
· numbers (integer or real), strings, dates, Boolean values, passwords - "primitive data types"
· files of types predefined, - "files"
· values of some lists. - "keys". Lists are types. Any such list consists of and only of objects of one type.

Every type A is set of such named elements. When type A inherit from type B it means "A set of elements" includes "B set of elements" as its part.

1.8 Additional operations
If you are a user you can come in. So every user has name and password. You can create object (see above). You can create a copy of object. You can create a shortcut to object. Shortcut works as a view. You can see object but you cannot change it. You can move object to another parent. You can send object to another parent behind your view if another user tells you how to find the parent. You can send an object to some list (object of type GROUP). You can sent object back. Objects of some types you can execute as procedures

2 Language
2.1 Language to declare and to act
Create type XXX inherited from type VVV
Create type XXX included into type VVV
Drop type XXX

Add to type XXX data element VVV
Drop from type XXX data element VVV

Create object YYY of type VVV under object XXX
Move object XXX under VVV

Create copy of VVVV named XXX
Create shortcut of XXX named VVV

Create and move copy of XXX under VVV
Create and move shortcut of XXX under VVV

Delete object XXX
Update object XXX set VVVV

Set flag XXX to user VVV

Send object XXX to user VVV
Send object XXX to group VVV
Send object XXX back

Execute type XXX as procedure
Stop execute type XXX as procedure

2.2 Statements before the start
Create type OBJECT

Add to type OBJECT data element CODE text
Add to type OBJECT data element NAME text

Add to type OBJECT data element COMMENT text
Add to type OBJECT data element STATUS text

Create object OBJECT of type OBJECT

Create type XUSER inherited from OBJECT
Add to type XUSER data element PASSWORD password

Create object SYSADMIN of type XUSER under OBJECT
Set flag ISADMIN to user SYSADMIN

Create type LICENSE included in XUSER only for flag ISADMIN
Add to type LICENSE data element LICTYPE link to TYPE

Create type FOLDER included in any type

Create type POSTOFFICE auto when (send object XXX to group VVV) under VVV with name XXX
Execute type POSTOFFICE as procedure

Create type QUERY included in XUSER only for flag ISADMIN execute
Create type DOCUMENT included in FOLDER
Create type WEBPAGE included in FOLDER execute