chore: remove deprecated kcl-openapi tool links

Signed-off-by: peefy <[email protected]>
kcl-lang · Nov 29, 2023 · 45afd2a · 45afd2a
1 parent b1796ef
commit 45afd2a
Show file tree

Hide file tree

Showing 35 changed files with 39 additions and 39 deletions.
diff --git a/docs/user_docs/guides/working-with-konfig/1-overview.md b/docs/user_docs/guides/working-with-konfig/1-overview.md
@@ -28,9 +28,9 @@ Konfig provides users with an out-of-the-box and highly abstract configuration i
 - **Core model**:
   - **Front-end model**: The front-end model is the "user interface", which contains all configurable attributes exposed to users on the platform side. Some repetitive and deducible configurations are omitted, and essential attributes are abstracted and exposed to users. It has user-friendly features, such as `server.k`.
   - **Back-end model**: The back-end model is "model implementation", which is the model that makes the properties of the front-end model effective. It mainly contains the rendering logic of the front-end model instance. The back-end model can use KCL to write validation, logic judgment, code fragment reuse and other code to improve the reusability and robustness of the configuration code, and is not sensitive to users, such as `server_backend.k`.
-- **Domain model**: It is a model that does not contain any implementation logic and abstraction. It is often generated by tool transformation and does not need to be modified. It corresponds to the real effective YAML attribute one by one. The domain model needs to be further abstracted and is generally not directly used by users. For example, `kusion_kubernetes` is the domain model library of Kubernetes scenarios.
+- **Domain model**: It is a model that does not contain any implementation logic and abstraction. It is often generated by tool transformation and does not need to be modified. It corresponds to the real effective YAML attribute one by one. The domain model needs to be further abstracted and is generally not directly used by users. For example, `k8s` is the domain model library of Kubernetes scenarios.
 
-In addition, the core model simplifies the configuration code of front-end users through two layers of abstraction: the front-end model and the back-end model. The domain model is automatically generated through the [KCL OpenAPI tool](/docs/tools/cli/openapi/quick-start).
+In addition, the core model simplifies the configuration code of front-end users through two layers of abstraction: the front-end model and the back-end model. The domain model is automatically generated through the KCL import tool.
 
 ## Docs
 

diff --git a/...-plugin-content-docs/current/user_docs/guides/working-with-konfig/1-overview.md b/...-plugin-content-docs/current/user_docs/guides/working-with-konfig/1-overview.md
@@ -28,9 +28,9 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
 - **核心模型**：
   - **前端模型**：前端模型即「用户界面」，包含平台侧暴露给用户的所有可配置属性，其中省略了一些重复的、可推导的配置，抽象出必要属性暴露给用户，具有用户友好的特性，比如 server.k。
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
-- **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
+- **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，k8s 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL Import 工具自动生成。
 
 ## 文档
 

diff --git a/...n-content-docs/version-0.4.4/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.4.4/user_docs/guides/working-with-konfig/1-overview.md
@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。
diff --git a/...n-content-docs/version-0.4.5/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.4.5/user_docs/guides/working-with-konfig/1-overview.md
@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。
diff --git a/...n-content-docs/version-0.4.6/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.4.6/user_docs/guides/working-with-konfig/1-overview.md
@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。
diff --git a/...n-content-docs/version-0.5.0/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.5.0/user_docs/guides/working-with-konfig/1-overview.md
@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。
diff --git a/...n-content-docs/version-0.5.1/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.5.1/user_docs/guides/working-with-konfig/1-overview.md
@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。
diff --git a/...n-content-docs/version-0.5.2/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.5.2/user_docs/guides/working-with-konfig/1-overview.md
@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。
diff --git a/...n-content-docs/version-0.5.3/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.5.3/user_docs/guides/working-with-konfig/1-overview.md
@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。
diff --git a/...n-content-docs/version-0.5.4/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.5.4/user_docs/guides/working-with-konfig/1-overview.md
@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。
diff --git a/...n-content-docs/version-0.5.5/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.5.5/user_docs/guides/working-with-konfig/1-overview.md
@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。
diff --git a/...n-content-docs/version-0.5.6/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.5.6/user_docs/guides/working-with-konfig/1-overview.md
@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。
diff --git a/...n-content-docs/version-0.6.0/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.6.0/user_docs/guides/working-with-konfig/1-overview.md
@@ -27,4 +27,4 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
 - **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL OpenAPI 工具自动生成。
diff --git a/...n-content-docs/version-0.7.0/user_docs/guides/working-with-konfig/1-overview.md b/...n-content-docs/version-0.7.0/user_docs/guides/working-with-konfig/1-overview.md
@@ -28,9 +28,9 @@ Konfig 提供给用户开箱即用、高度抽象的配置界面，模型库最
 - **核心模型**：
   - **前端模型**：前端模型即「用户界面」，包含平台侧暴露给用户的所有可配置属性，其中省略了一些重复的、可推导的配置，抽象出必要属性暴露给用户，具有用户友好的特性，比如 server.k。
   - **后端模型**：后端模型是「模型实现」，是让前端模型属性生效的模型，主要包含前端模型实例的渲染逻辑，后端模型中可借助 KCL 编写校验和逻辑判断等以提高配置代码复用性和健壮性，对用户不感知，比如 server_backend.k
-- **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，kusion_kubernetes 是 Kubernetes 场景的底层模型库。
+- **领域模型**：是不包含任何实现逻辑和抽象的模型，往往由工具转换生成，无需修改，和真正生效的 YAML 属性一一对应，底层模型需要经过进一步抽象，一般不直接被用户使用。比如，k8s 是 Kubernetes 场景的底层模型库。
 
-此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 [KCL OpenAPI 工具](/docs/tools/cli/openapi/quick-start) 自动生成。
+此外，核心模型内部通过前端模型和后端模型两层抽象简化前端用户的配置代码，底层模型则是通过 KCL Import 工具自动生成。
 
 ## 文档
 

diff --git a/versioned_docs/version-0.4.3/user_docs/guides/configuration.md b/versioned_docs/version-0.4.3/user_docs/guides/configuration.md
@@ -7,7 +7,7 @@ sidebar_position: 1
 
 The core features of KCL are its **modeling** and **constraint** capabilities, and the basic functions of KCL revolve around the two core features. In addition, KCL follows the user-centric configuration concept to design its basic functions, which can be understood from two aspects:
 
-- **Domain model-centric configuration view**: With the rich features of KCL language and [KCL OpenAPI](https://kcl-lang.github.io/docs/tools/cli/openapi/quick-start) tools, we can directly integrate a wide range of well-designed models in the community into KCL (such as the K8s resource model). We can also design and implement our own KCL models or libraries according to different scenarios, forming a complete set of domain models for other configuration end users to use.
+- **Domain model-centric configuration view**: With the rich features of KCL language and KCL OpenAPI tools, we can directly integrate a wide range of well-designed models in the community into KCL (such as the K8s resource model). We can also design and implement our own KCL models or libraries according to different scenarios, forming a complete set of domain models for other configuration end users to use.
 - **End user-centric configuration view**: With KCL's code encapsulation, abstraction and reuse capabilities, the model architecture can be further abstracted and simplified (for example, the K8s resource model is abstracted into an application-centered server model) to **minimize the end user configuration input**, simplify the user's configuration interface, and facilitate manual or automatic API modification.
 
 No matter what configuration view is centered on, for configuration code, there are requirements for configuration data constraints, such as type constraints, required/optional constraints on configuration attributes, range constraints, and immutability constraints. This is also one of the core issues KCL is committed to solving.