rename terminology "virtual table(vtable)" to "attribute"

6 files changed, 38 insertions, 38 deletions

diff --git a/docs/getting_started.md b/docs/getting_started.md
index bef190b..49cb606 100644
--- a/docs/getting_started.md
+++ b/docs/getting_started.md
@@ -61,7 +61,7 @@ Table schema is stored in a json file(such as table_info.conf), which is loaded
             "group_id":1,
             "rule_id":2,
             "not_flag":4,
-            "virtual_table_name":5,
+            "attribute_name":5,
             "clause_index":6
         }
     },
diff --git a/docs/history.md b/docs/history.md
index e9c99d0..84d4c75 100644
--- a/docs/history.md
+++ b/docs/history.md
@@ -8,7 +8,7 @@
 | v3.1.20| 2021-4-28 | Add explanation for loading gzip-compressed JSON files | Zheng Chao  |
 | v3.1.5 | 2021-3-12 | Add matching examples for callback class FQDN table | Zheng Chao  |
 | v3.1.4 | 2020-11-04| When content foreign key is "null," it represents an empty file   | Zheng Chao  |
-| v3.1.1 | 2020-9-27 | Add explanation for creating virtual tables on multiple different types of physical tables | Zheng Chao  |
+| v3.1.1 | 2020-9-27 | Add explanation for creating attributes on multiple different types of physical tables | Zheng Chao  |
 | v3.1.0 | 2020-9-18 | Add FQDN callback table | Zheng Chao  |
 | v3.0.4 | 2020-8-17 | Add extended numerical domain configuration interval_plus  | Zheng Chao  |
 | v3.0   | 2020-6-29 | Maat 3.0, support clauses, original grouping table split into grouping relationship table and grouping compilation table | Zheng Chao  |
@@ -16,7 +16,7 @@
 | v2.8   | 2020-2-11 | Support Hit Path  | Zheng Chao  |
 | v2.8   | 2020-2-4  | Support sorting strategies by Evaluation Order  | Zheng Chao  |
 | v2.8   | 2020-1-22 | Maat JSON file encryption support, see 17.3   | Zheng Chao  |
-| v2.8   | 2019-7-28 | 1. No longer compatible with no grouping tables  2. Support virtual tables | Zheng Chao  |
+| v2.8   | 2019-7-28 | 1. No longer compatible with no grouping tables  2. Support attributes | Zheng Chao  |
 | v2.7.2 | 2019-7-10 | Expand IP configuration table to support CIDR format | Zheng Chao  |
 | v2.7.1 | 2019-5-23 | Rename rich IP class configuration table to extended IP configuration table  | Zheng Chao  |
 | v2.7.0 | 2019-5-12 | 1. Add explanation for subgroup relationships  2. Add explanation for rich IP class configuration | Zheng Chao  |
diff --git a/docs/logical_combinations.md b/docs/logical_combinations.md
index 7653a40..0716393 100644
--- a/docs/logical_combinations.md
+++ b/docs/logical_combinations.md
@@ -42,7 +42,7 @@ Before showing how to configure the specific rules, we need some raw materials (
 
 ```bash
 rule(rule) = clause1 & clause2
-              = {vtable1, group1, clause_index1} & {vtable2, group2, clause_index2}
+              = {attribute1, group1, clause_index1} & {attribute2, group2, clause_index2}
               = {2, 211, 1} & {1, 201, 2}
 ```
 
@@ -53,7 +53,7 @@ rule(rule) = clause1 & clause2
 
 ```bash
 rule(rule) = clause1 & clause2
-              = {vtable1, group1, clause_index1} & {vtable2, group2, clause_index2}
+              = {attribute1, group1, clause_index1} & {attribute2, group2, clause_index2}
               = {2, 211, 1} & {3, 221, 2}
 ```
 
@@ -74,7 +74,7 @@ group_name: "152_mail_addr" and group_name: "interval_group_refered" are two cla
 
 ```bash
 rule(rule) = clause1 & clause2
-              = {vtable1, (group1 | group2), clause_index1} & {vtable2, group3, clause_index2}
+              = {attribute1, (group1 | group2), clause_index1} & {attribute2, group3, clause_index2}
               = {2, (211 | 212), 1} & {1, 201, 2}
 ```
 
@@ -86,7 +86,7 @@ rule(rule) = clause1 & clause2
 
 ```bash
 rule(rule) = clause1 & clause2
-              = {vtable1, group1, clause_index1} & {vtable2, (group2 | group3), clause_index2}
+              = {attribute1, group1, clause_index1} & {attribute2, (group2 | group3), clause_index2}
               = {2, 211, 1} & {3, (221 | 222), 2}
 ```
 
@@ -106,7 +106,7 @@ group_name: "152_mail_addr" contains two regions(items) with a logical `OR` rela
 
 ```bash
 rule(rule) = clause1 & !clause2
-              = {vtable1, group1, clause_index1} & !{vtable2, group2, clause_index2}
+              = {attribute1, group1, clause_index1} & !{attribute2, group2, clause_index2}
               = {2, 211, 1} & !{1, 201, 2}
 ```
 
@@ -118,7 +118,7 @@ rule(rule) = clause1 & !clause2
 
 ```bash
 rule(rule) = clause1 & !clause2
-              = {vtable1, group1, clause_index1} & !{vtable2, (group2 | group3), clause_index2}
+              = {attribute1, group1, clause_index1} & !{attribute2, (group2 | group3), clause_index2}
               = {2, 211, 1} & !{3, (221 | 222), 2}
 ```
 
@@ -148,7 +148,7 @@ super_group1 = group1 exclude group2
 And then configure the rule.
 ```bash
 rule(rule) = clause1 & clause2
-              = {vtable1, super_group1, clause_index1} & {vtable2, group2, clause_index2}
+              = {attribute1, super_group1, clause_index1} & {attribute2, group2, clause_index2}
               = {2, (210 exclude 211), 1} & {1, 201, 2}
 ```
 
@@ -167,7 +167,7 @@ super_group2 = group2 exclude group3
 And then configure the rule.
 ```bash
 rule(rule) = clause1 & clause2
-              = {vtable1, group1, clause_index1} & {vtable2, super_group2, clause_index2}
+              = {attribute1, group1, clause_index1} & {attribute2, super_group2, clause_index2}
               = {2, 211, 1} & {1, (202 exclude 201), 2}
 ```
 
diff --git a/docs/maat_table.md b/docs/maat_table.md
index 8018afe..06763ea 100644
--- a/docs/maat_table.md
+++ b/docs/maat_table.md
@@ -7,7 +7,7 @@ The maat table consists of two parts: `schema` and `runtime`, which is the core
 
 ## 1. Table schema
 
-Maat tables are divided into two categories: physical tables that actually exist in the database and virtual tables that reference physical tables.
+Maat tables are divided into two categories: physical tables that actually exist in the database and attributes that reference physical tables.
 
 The types of physical tables are as follows:
 - [item table](#11-item-table)
@@ -22,7 +22,7 @@ The types of physical tables are as follows:
 
 Different physical tables can be combined into one table, see [conjunction table](#110-conjunction-table)
 
-A virtual table can only reference one physical table or conjuntion table, see [virtual table](#111-virtual-table)
+A attribute can only reference one physical table or conjuntion table, see [attribute](#111-attribute)
 
 ### 1.1 <a name='Itemtable'></a> Item table
 
@@ -257,7 +257,7 @@ Describe the relationship between group and rule.
 | **rule_id**    | LONG LONG     | rule id |
 | **is_valid**      | INT           | 0(invalid), 1(valid) |
 | **not_flag**      | INT           | logical 'NOT', identify a NOT clause, 0(no) 1(yes) |
-| **virtual_table** | VARCHAR2(256) | virtual table name, NOT NULL |
+| **attribute** | VARCHAR2(256) | attribute name, NOT NULL |
 | **Nth_clause**    | INT           | the clause seq in (conjunctive normal form)CNF, from 0 to 7. groups with the same clause ID are logical 'OR' |
 
 NOTE: If group_id is invalid in xx_item table, it must be marked as invalid in this table.
@@ -370,11 +370,11 @@ For example: HTTP_REGION is the conjunction of HTTP_URL and HTTP_HOST.
 
 `Note`: Only physical tables support conjunction.
 
-### 1.11 <a name='VirtualTable'></a> virtual table
+### 1.11 <a name='Attribute'></a> attribute
 
-A physical table refers to a table that physically exists in the database. In contrast, there are no virtual tables in the database. Virtual tables are merely references to physical tables, where one virtual table can only reference one physical table. If you want to reference multiple physical tables of the same type, you need to first combine these physical tables into a conjunction table, and then have the virtual table reference it. A physical table can be referenced by multiple virtual tables.
+A physical table refers to a table that physically exists in the database. In contrast, there are no attributes in the database. Attributes are merely references to physical tables, where one attribute can only reference one physical table. If you want to reference multiple physical tables of the same type, you need to first combine these physical tables into a conjunction table, and then have the attribute reference it. A physical table can be referenced by multiple attributes.
 
-Virtual tables are often used for different traffic attributes, where different virtual tables represent different traffic attributes, such as HTTP_HOST, HTTP_URL, and so on.
+Attributes are often used for different traffic attributes, where different attributes represent different traffic attributes, such as HTTP_HOST, HTTP_URL, and so on.
 
 ### 1.12 <a name='ForeignFiles'></a>Foreign Files
 
@@ -445,21 +445,21 @@ In addition to the rule table, there is also the group2rule table in the table s
 
 1. For expressions without NOT-clauses, returning the matched rule_id:
 
-    * rule1 = clause1 & clause2 = {vtable1, g1} & {vtable2, g2}
+    * rule1 = clause1 & clause2 = {attribute1, g1} & {attribute2, g2}
 
-    * rule2 = clause1 & clause2 = {vtable1, g2} & {vtable2, g3}
+    * rule2 = clause1 & clause2 = {attribute1, g2} & {attribute2, g3}
 
-    Given the matched vtable_id and group_id, all matching rule_ids can be provided. For example, if scanning vtable1 matches g2 and vtable2 matches g3, rule_runtime will return the matched rule_id 2.
+    Given the matched attribute_id and group_id, all matching rule_ids can be provided. For example, if scanning attribute1 matches g2 and attribute2 matches g3, rule_runtime will return the matched rule_id 2.
 
 2. For expressions with NOT-clauses, returning the matched rule_id:
 
-    * rule3 = clause1 & !clause2 = {vtable1, g1} & !{vtable2, g2}
+    * rule3 = clause1 & !clause2 = {attribute1, g1} & !{attribute2, g2}
 
-    * rule4 = !clause1 & clause2 = !{vtable1, g2} & {vtable2, g3}
+    * rule4 = !clause1 & clause2 = !{attribute1, g2} & {attribute2, g3}
 
-    If scanning vtable1 matches g1 and vtable2 matches g3, rule_runtime will return the matched rule_id 4.
+    If scanning attribute1 matches g1 and attribute2 matches g3, rule_runtime will return the matched rule_id 4.
 
-3. If a rule_id is matched, the full hit path can be obtained: **item_id -> group_id ->** {super_group_id} -> clause{**vtable_id, not_flag, clause_index} -> rule_id**. If the matched group is not referenced by a rule, a half hit path can be obtained: **item_id -> group_id** -> {super_group_id}.
+3. If a rule_id is matched, the full hit path can be obtained: **item_id -> group_id ->** {super_group_id} -> clause{**attribute_id, not_flag, clause_index} -> rule_id**. If the matched group is not referenced by a rule, a half hit path can be obtained: **item_id -> group_id** -> {super_group_id}.
 
 4. Getting the matched group_ids and the count of hit groups.
 
@@ -473,9 +473,9 @@ Rule runtime loads the rule table and group2rule table configurations into memor
 
 1. All clause_ids under the same rule are used to construct AND expressions, and all rule AND expressions are used to build a bool_matcher.
 
-2. For not_flag=0 (clauses), a `clause_id hash` is built, key:{group_id, vtable_id, not_flag}, value:clause_id.
+2. For not_flag=0 (clauses), a `clause_id hash` is built, key:{group_id, attribute_id, not_flag}, value:clause_id.
 
-3. For not_flag=1 (NOT-clauses), a `NOT_clause_id hash` is built, key:{group_id, vtable_id, not_flag}, value:clause_id.
+3. For not_flag=1 (NOT-clauses), a `NOT_clause_id hash` is built, key:{group_id, attribute_id, not_flag}, value:clause_id.
 
 * **Data Plane**
 
@@ -485,17 +485,17 @@ On the data plane, services are provided externally through the maat API, primar
 
 * The hit item_id and group_id form a half-hit path.
 
-* The group_id that is hit and the scanned `vtable_id` form the key {group_id, vtable_id, 0}. This key is used to find the `hit clause_ids` in the clause_id hash.
+* The group_id that is hit and the scanned `attribute_id` form the key {group_id, attribute_id, 0}. This key is used to find the `hit clause_ids` in the clause_id hash.
 
-* Use the key {group_id, vtable_id, 1} to search for NOT_clause_ids in the NOT_clause_id hash and cache them as `exclude clause_ids`. These clause_ids need to be removed from all clause_ids that are eventually hit. This is because the scan hit {group_id, vtable_id, 0} => clause_id, leading to the deduction that {group_id, vtable_id, 1} => NOT_clause_id does not hit.
+* Use the key {group_id, attribute_id, 1} to search for NOT_clause_ids in the NOT_clause_id hash and cache them as `exclude clause_ids`. These clause_ids need to be removed from all clause_ids that are eventually hit. This is because the scan hit {group_id, attribute_id, 0} => clause_id, leading to the deduction that {group_id, attribute_id, 1} => NOT_clause_id does not hit.
 
-* Identify the group_ids in vtable_id table that appear in the NOT_clause and add them to the `NOT_clause_group` set. Ensure that this set does not contain any group_id that was hit during scanning. If any such group_id is present, remove it from the set to form the final `NOT_clause_group` for the vtable_id table.
+* Identify the group_ids in attribute_id table that appear in the NOT_clause and add them to the `NOT_clause_group` set. Ensure that this set does not contain any group_id that was hit during scanning. If any such group_id is present, remove it from the set to form the final `NOT_clause_group` for the attribute_id table.
 
 * Use the hit clause_ids to determine if there are any hit rule_ids. If there are, populate the half-hit path which will become full-hit path.
 
 2. **maat_scan_not_logic**: This interface is used to activate NOT-clause logic.
 
-* Traverse the `NOT_clause_group` of `vtable_id`. For each `group_id`, form a key `{group_id, vtable_id, 1}` to obtain the `NOT_clause_id`. If it is in the `exclude clause_ids` set, ignore it; otherwise, add it to the `all hit clause_ids` set as a hit `NOT_clause_id`, and record the half-hit path of the NOT-clause.
+* Traverse the `NOT_clause_group` of `attribute_id`. For each `group_id`, form a key `{group_id, attribute_id, 1}` to obtain the `NOT_clause_id`. If it is in the `exclude clause_ids` set, ignore it; otherwise, add it to the `all hit clause_ids` set as a hit `NOT_clause_id`, and record the half-hit path of the NOT-clause.
 
 * Use the `all hit clause_ids` to calculate if there are any newly hit rule_ids. If there are, populate the half-hit path of the NOT-clause which will become full-hit path.
 
diff --git a/docs/overview.md b/docs/overview.md
index b102b1d..ba37bd5 100644
--- a/docs/overview.md
+++ b/docs/overview.md
@@ -28,7 +28,7 @@ As shown in the diagram below, maat organizes and abstracts configurations using
 
 In addition, groups support nesting. For more detailed information, please refer to [group hierarchy](./group_hierarchy.md).
 
-If we define literal_id = {virtual_table_id, group_id}, then a literal is composed of one or more literal_ids. The multiple literal_ids that form the same clause have a logical “OR” relationship. The multiple clauses that form the same rule have a logical “AND” relationship, and there can be a maximum of 8 clauses within the same rule. In addition, the clause itself supports logical "NOT".
+If we define literal_id = {attribute_id, group_id}, then a literal is composed of one or more literal_ids. The multiple literal_ids that form the same clause have a logical “OR” relationship. The multiple clauses that form the same rule have a logical “AND” relationship, and there can be a maximum of 8 clauses within the same rule. In addition, the clause itself supports logical "NOT".
 
 <img src="./imgs/rule_diagram.png" width="800" height="450" > 
 
diff --git a/docs/terminology.md b/docs/terminology.md
index 6d695fa..a9d8fac 100644
--- a/docs/terminology.md
+++ b/docs/terminology.md
@@ -6,7 +6,7 @@
 * [Clause(Condition)](#clause)
 * [Literal](#literal)
 * [Physical table](#physical-table)
-* [Virtual table](#virtual-table)
+* [Attribute](#attribute)
 * [Table schema](#table-schema)
 * [Table runtime](#table-runtime)
 * [Table rule](#table-ruleconfiguration)
@@ -48,7 +48,7 @@ The relationship between group and group is stored in the [group2group table](./
 
 ## Rule(Policy)
 
-A conjunctive normal form(CNF) consisting of multiple groups and virtual tables.
+A conjunctive normal form(CNF) consisting of multiple groups and attributes.
 
 `Note`: A rule can contain up to 8 clauses and multiple clauses in the same rule can be logical 'AND' and logical 'NOT' relationships.
 
@@ -64,19 +64,19 @@ Clauses are divided into two categories based on whether they contain the logica
 
 ## Literal
 
-A Literal consists of `vtable_id(virtual table id)` and `group_id`. During the rules loading process, a unique clause_id  will be generated based on the combination of virtual table_id and group_id in the same clause.
+A Literal consists of `attribute_id(attribute id)` and `group_id`. During the rules loading process, a unique clause_id  will be generated based on the combination of attribute_id and group_id in the same clause.
 
 ## Physical table
 
 Different rules are stored in different tables in the actual database, including [item table](./maat_table.md#11-item-table), [rule table](./maat_table.md#12-rule-table), [group2rule table](./maat_table.md#13-group2rule-table), [group2group table](./maat_table.md#14-group2group-table), and [xx_plugin table](./maat_table.md#15-plugin-table), and so on.
 
-## Virtual table
+## Attribute
 
-A virtual table references a physical table. In practice, network traffic attributes are commonly used as virtual table, such as HTTP_HOST, SSL_SNI, etc. The constraints of virtual tables are as follows:
+A attribute references a physical table. In practice, network traffic attributes are commonly used as attribute, such as HTTP_HOST, SSL_SNI, etc. The constraints of attributes are as follows:
 
-* A virtual table can only reference one physical table. If it need to reference multiple physical tables of the same type, these physical tables can be first joined together into one table and then referenced.
+* A attribute can only reference one physical table. If it need to reference multiple physical tables of the same type, these physical tables can be first joined together into one table and then referenced.
 
-* A physical table can be referenced by different virtual tables. For example, the keyword_table can be referenced by two virtual tables, http_request_body_virt and http_response_body_virt.
+* A physical table can be referenced by different attributes. For example, the keyword_table can be referenced by two attributes, http_request_body_virt and http_response_body_virt.
 
 <img src="./imgs/virt-phy-mapping.png" width="300" height="150" >