COnsider:
MySchema:((Name.Address,Height),(g1,g2,g3,g4))
As a definition in TE, this means the schema defined in the first part applies to each of the gi, and the gi are conformal graphs. The schema appears right at the head of a graph with a forward pointer encompassing the domain of the definition.
The machine knows that tables can have an attribute SQUARE. On these tables the schema is automatic:
SqlSquareSchema:((col1_name,col2_name..), set of constant sized rows)
The number of columns in each row fixed by the number of columns names. Each row member is a dot sequence, and each row a comma. Gone over this, but in version 2 it is the official schema for SQUARE.
There are two function that maintain partitioned match conditions, the schema and the data part. Standard table with attribute TRIPLE, rerun the schema sequence from table, SQUARE keep the column name list in local memory. Schema takes wild cards, why not. Same rules apply. Schema is just a layer of the total output filtering process. The approach is to make the thing work for triple, then simulate the schema sequence (including a null schema) when the schema function needs it for filtering.
Schema, supports nested form. The Schema, (Name.Address) does not prevent elements of the form:
(Joe.Nowhere, but here is an arbitrary size list of other things).
The first two elements under Joe meet the schema, the rest is self directed.
So the machine is accepting some known attributes about tables. That implies sometime in the future a list graph table names that can declare their attribute type. But, for now, some very ugly punctuation will do. Here is the current ugly set:
* ? , . ( ) : $ _ ! and keywords.
No comments:
Post a Comment