Configuration architecture language design method

Abstract

In a software system, a traditional configuration format for configuration management is difficult to meet the high reliability requirement under a complex configuration scene due to lack of a structural verification mechanism, and the problems of insufficient verification capability, action range coupling and poor readability and maintainability exist. In order to solve the problems of traditional configuration, the invention provides a configuration architecture language design method, and relates to the technical field of computer software. And through technologies such as a dynamic configuration security mechanism and logic decoupling, the reliability and the development efficiency of the whole configuration life cycle are improved, and the blank between a traditional configuration format and a verification mechanism is filled. The method is not only suitable for being used as a static configuration definition language, but also can be deeply integrated with a tool chain, automatic configuration document generation, IDE intelligent completion and multi-environment configuration verification are achieved, full-life-cycle support is achieved, and the reliability and development efficiency of configuration management are remarkably improved. The method can be widely applied to the fields of micro-services, DevOps tool chains and the like.

Description

Technical Field

[0001] The present invention relates to the field of computer software technology, and in particular to a configuration schema language (Config Schema Language, CSL) design method. Background Art

[0002] In modern software systems, the importance of configuration management is becoming increasingly prominent. As the scale and complexity of systems continue to grow, configuration files often carry a large number of dynamic parameters, nested structures, and environmental differences. To ensure the stability and maintainability of the system, the development team urgently needs a method that can clearly express the configuration structure and has strong verification capabilities. Traditional configuration formats (such as JSON, YAML, and TOML) lack structural verification mechanisms and are difficult to meet the high reliability requirements in complex configuration scenarios. They rely on external tools (such as JSON Schema) for verification, but there are still problems such as insufficient verification capabilities, weak support for dynamic keys, scope coupling, and poor readability and maintainability. As a result, many teams have to rely on additional scripts or conventions for configuration management, which increases system complexity and the probability of errors.

[0003] A configuration architecture language design method that addresses the lack of structured verification capabilities of traditional configuration formats (such as JSON and YAML) in complex scenarios through dynamic configuration security mechanisms and logical decoupling. It provides a more structured, highly readable, and maintainable way to define and verify complex configurations, improving reliability and development efficiency throughout the configuration lifecycle and filling the gap between traditional configuration formats and verification mechanisms. CSL is not only suitable for use as a static configuration definition language, but also can be deeply integrated with toolchains to enable automatic configuration document generation, IDE intelligent completion, and multi-environment configuration verification, providing full lifecycle support and significantly improving configuration management reliability and development efficiency. Summary of the Invention

[0004] A configuration architecture language design method solves the shortcomings of existing configuration languages ​​(such as JSON Schema and TypeScript) in terms of dynamic structure verification, constraint logic expression, scope isolation, and tool chain support, as well as the contradiction between security and efficiency in dynamic configuration scenarios, by integrating wildcard dynamic structure with static type verification, local scope constraints, expressive conditional logic, declarative relationship modeling mechanism, "controlled / uncontrolled" strategy, and multiple verification technologies. In addition, CSL is deeply integrated with the tool chain to achieve automatic generation of configuration documents, IDE intelligent completion, and multi-environment configuration verification, significantly improving the reliability and development efficiency of configuration management. The present invention can be widely used in fields such as microservices and DevOps tool chains, significantly improving the maintainability and development efficiency of configuration, and has high commercial value and technical barriers.

[0005] The present invention proposes a configuration framework language (CSL) design method, the method comprising:

[0006] 1. Capture usage requirements and establish the basic architecture of CSL.

[0007] Based on the captured external usage requirements, the basic architecture of the designed CSL is as follows:

[0008]

[0009]

[0010]

[0011] 2. Fusion of wildcard dynamic structure and static verification.

[0012] CSL provides a wildcard key mechanism that allows developers to define sub-configurations with undefined key names but uniform structures. At the same time:

[0013] (1) Support type constraints and annotations;

[0014] (2) Local constraints can be defined for all wildcard keys;

[0015] (3) The key name itself can be verified (all_keys(...)match);

[0016] CSL achieves a balance between concise expression and fine control.

[0017] 3. Local scope constraint mechanism.

[0018] In CSL, each nested level (including wildcard blocks) can have an independent constraints block, which strictly isolates the scope and only acts on the fields of the current level. It does not allow access to upper-level or global fields to prevent global pollution.

[0019] CSL achieves true scope isolation at the syntax and semantic levels, making constraint logic more intuitive, secure, and easy to maintain, and achieving scope isolation and clear constraint logic.

[0020] 4. Expressive conditional logic.

[0021] CSL uses C-style expression syntax (?:, ==, &&, exists(), etc.) to write logical verification statements. CSL's validate provides programmatic verification capabilities while retaining the simplicity of a domain-specific language (DSL).

[0022] 5. Declarative relational modeling.

[0023] CSL uses a declarative constraint relationship model to express state conflicts and field dependencies (such as 'conflicts' and 'requires') in business logic;

[0024] Compared to the lengthy nested structure of JSON Schema, CSL provides a language-level mechanism with clear semantics and neat structure, improving maintainability and IDE support (clear relationships facilitate automatic prompting and validation).

[0025] 6. “Controlled / uncontrolled” strategy.

[0026] In CSL, the "controlled / uncontrolled" strategy for designing any{} and any[] is as follows:

[0027] (1) explicitly allow uncontrolled structures (any{} / any[]);

[0028] (2) Restrictions cannot be nested;

[0029] (3) IDE tools need to prompt warnings (flexible design: tolerant during development, vigilant during production)

[0030] CSL clarifies configuration boundaries through explicit settings, avoiding the semantic ambiguity of 'additionalProperties:true' in JSON Schema.

[0031] 7. Multiple verification technologies.

[0032] CSL supports subset validation ('subset' function) and batch key validation ('all_keys', etc.) with explicit syntax support, ensuring transparency and controllability of business rules (such as plugin validity checks).

[0033] Among them, subset verification is used to verify the inclusion relationship between arrays (or object arrays), allowing the comparison key to be set through properties to achieve flexible comparison of object arrays;

[0034] Batch key verification, through count_keys(), all_keys(), wildcard_keys() and match, start_with, contains, etc., verifies structural rules and implements "batch regular expression verification of key names", which is very suitable for complex configuration scenarios (such as multi-environment builds and plug-in naming rules).

[0035] 8. Rich annotation system and tool chain-friendly design.

[0036] CSL significantly improves development efficiency through a rich annotation system (such as '@min', '@regex') and toolchain-friendly design.

[0037] The annotation system can add annotations to fields, provide type-level restrictions, and make constraints intuitive and reusable.

[0038] The full language structure design of tool chain friendliness and declaration-driven design focuses on parsability and generability, supports LSP / IDE automatic prompts, document generation and pre-deployment verification, automatically derives type trees, generates documents or code templates, and takes into account both human and machine friendliness.

[0039] A configuration architecture language design method solves the problem of traditional configuration formats (such as JSON, YAML) lacking structured verification capabilities in complex scenarios through dynamic configuration security mechanisms, logical decoupling and other technologies, and provides a more structured, highly readable and maintainable way to define and verify complex configurations, thereby improving the reliability and development efficiency of the entire configuration life cycle and filling the gap between traditional configuration formats and verification mechanisms. CSL is not only suitable for use as a static configuration definition language, but can also be deeply integrated with the tool chain to achieve automatic generation of configuration documents, IDE intelligent completion and multi-environment configuration verification, achieving full life cycle support and significantly improving the reliability and development efficiency of configuration management. The present invention can be widely used in fields such as microservices and DevOps tool chains, significantly improving the maintainability and development efficiency of configuration, and has high commercial value and technical barriers. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 : A schematic diagram of a Web application configuration (WebAppConfig) configuration architecture language design method.

[0041] Figure 2 : A diagram of a CI / CD build configuration (BuildPipelineConfig) based on a configuration architecture language design method. DETAILED DESCRIPTION

[0042] To make the purpose, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0043] The features of various aspects of the embodiments of the present invention will be described in detail below. In the detailed description below, many specific details are provided to provide a comprehensive understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention can also be implemented without these specific details. The following description of the embodiments is merely intended to provide a better understanding of the present invention by illustrating examples of the present invention. The present invention is not limited to any specific settings and methods provided below, but rather covers all product structures, any improvements, replacements, etc. of the methods covered without departing from the spirit of the present invention. In the various drawings and the following description, well-known structures and technologies are not shown to avoid unnecessary ambiguity in the present invention.

[0044] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments can be combined with each other, and the embodiments can refer to and quote each other. The present invention will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0045] The present invention proposes a configuration architecture language design method. By integrating wildcard dynamic structure with static type verification, local scope constraints, expressive conditional logic, declarative relationship modeling mechanism, "controlled / uncontrolled" strategy, and multiple verification technologies, it solves the shortcomings of existing configuration languages ​​(such as JSON Schema and TypeScript) in dynamic structure verification, constraint logic expression, scope isolation, and tool chain support, as well as the contradiction between security and efficiency in dynamic configuration scenarios. In addition, CSL is deeply integrated with the tool chain to achieve automatic generation of configuration documents, IDE intelligent completion, and multi-environment configuration verification, significantly improving the reliability and development efficiency of configuration management. The present invention can be widely used in fields such as microservices and DevOps tool chains, significantly improving the maintainability and development efficiency of configuration, and has high commercial value and technical barriers.

[0046] The present invention provides a configuration architecture language design method, which includes the following methods:

[0047] 1. Capture usage requirements and establish the basic architecture of CSL.

[0048] Based on the captured external usage requirements, the basic architecture of the designed CSL is as follows:

[0049]

[0050]

[0051] 2. Fusion of wildcard dynamic structure and static verification.

[0052] CSL provides a wildcard key mechanism that allows developers to define sub-configurations with undefined key names but uniform structures. At the same time:

[0053] (1) Support type constraints and annotations;

[0054] (2) Local constraints can be defined for all wildcard keys;

[0055] (3) The key name itself can be verified (all_keys(...)match);

[0056] CSL achieves a balance between concise expression and fine control.

[0057] 3. Local scope constraint mechanism.

[0058] In CSL, each nested level (including wildcard blocks) can have an independent constraints block, which strictly isolates the scope and only acts on the fields of the current level. It does not allow access to upper-level or global fields to prevent global pollution.

[0059] CSL achieves true scope isolation at the syntax and semantic levels, making constraint logic more intuitive, secure, and easy to maintain, and achieving scope isolation and clear constraint logic.

[0060] 4. Expressive conditional logic.

[0061] CSL uses C-style expression syntax (?:, ==, &&, exists(), etc.) to write logical verification statements. CSL's validate provides programmatic verification capabilities while retaining the simplicity of DSL.

[0062] 5. Declarative relational modeling.

[0063] CSL uses a declarative constraint relationship model to express state conflicts and field dependencies (such as 'conflicts' and 'requires') in business logic.

[0064] Compared to the lengthy nested structure of JSON Schema, CSL provides a language-level mechanism with clear semantics and neat structure, improving maintainability and IDE support (clear relationships, easy automatic prompting and verification).

[0065] 6. “Controlled / uncontrolled” strategy.

[0066] In CSL, the "controlled / uncontrolled" strategy for designing any{} and any[] is as follows:

[0067] (1) explicitly allow uncontrolled structures (any{} / any[]);

[0068] (2) Restrictions cannot be nested;

[0069] (3) IDE tools need to prompt warnings (flexible design: tolerant during development, vigilant during production)

[0070] CSL clarifies configuration boundaries through explicit settings, avoiding the semantic ambiguity of 'additionalProperties:true' in JSON Schema.

[0071] 7. Multiple verification technologies.

[0072] CSL supports subset validation ('subset' function) and batch key validation ('all_keys', etc.) with explicit syntax support, ensuring transparency and controllability of business rules (such as plugin validity checks).

[0073] Among them, subset verification is used to verify the inclusion relationship between arrays (or object arrays), allowing the comparison key to be set through properties to achieve flexible comparison of object arrays;

[0074] Batch key verification, through count_keys(), all_keys(), wildcard_keys() and match, start_with, contains, etc., verifies structural rules and implements "batch regular expression verification of key names", which is very suitable for complex configuration scenarios (such as multi-environment builds and plug-in naming rules).

[0075] 8. Rich annotation system and tool chain-friendly design.

[0076] CSL significantly improves development efficiency through a rich annotation system (such as '@min', '@regex') and toolchain-friendly design.

[0077] The annotation system can add annotations to fields, provide type-level restrictions, and make constraints intuitive and reusable.

[0078] The full language structure design of tool chain friendliness and declaration-driven design focuses on parsability and generability, supports LSP / IDE automatic prompts, document generation and pre-deployment verification, automatically derives type trees, generates documents or code templates, and takes into account both human and machine friendliness.

[0079] A configuration architecture language design method that addresses the lack of structured verification capabilities in complex scenarios in traditional configuration formats (such as JSON and YAML) by integrating wildcard dynamic structures with static type verification, local scope constraints, expressive conditional logic, and declarative relational modeling mechanisms. It provides a more structured, expressive, and maintainable way to define and verify complex configurations, improving the reliability and development efficiency of the entire configuration lifecycle and filling the gap between traditional configuration formats and verification mechanisms. CSL is not only suitable for use as a static configuration definition language, but also can be deeply integrated with tool chains to achieve automatic generation of configuration documents, IDE intelligent completion, and multi-environment configuration verification, significantly improving the reliability and development efficiency of configuration management.

[0080] Example 1

[0081] Figure 1 It is a schematic diagram of a Web application configuration (WebAppConfig) of a configuration architecture language design method according to an embodiment of the present invention.

[0082] like Figure 1 As shown, the method includes the following steps:

[0083] Step 101: Capture requirements for web application configuration.

[0084] Capture the configuration requirements for a web application deployed in different environments (development, staging, production), including database connections, cache settings, debugging switches, etc., and establish a basic framework.

[0085]

[0086] Step 102: Create basic information for the application.

[0087] app_name:string@regex("^[a-z0-9-_]+$");

[0088] environment:"development"|"staging"|"production"="development";

[0089] debug_mode?:boolean;

[0090] production_mode?:boolean;

[0091] Step 103: Establish database link information.

[0092]

[0093] Step 104: Cache settings.

[0094]

[0095] Step 105. Login settings.

[0096]

[0097] Step 106: Constraints for the production model.

[0098]

[0099] Step 107: Login mode constraints.

[0100]

[0101] Step 108. Constraints for debug and production modes.

[0102]

[0103] Step 109: The configuration for the web application is completed.

[0104] In summary, a pseudo-code example of CI / CD build configuration for a configuration architecture language design method is as follows:

[0105]

[0106]

[0107] After completing all steps, a web application configuration using a configuration architecture language design method has been completed. In this embodiment, logical associations between configuration rules are implemented using 'constraints'; database SSL is enforced in the production environment; if it is not enabled, the system automatically rejects the configuration, improving security; dynamic control of the log output location automatically forces the log path suffix to '.log'; and explicit restrictions on the coexistence of debug mode and production mode to prevent misconfiguration.

[0108] Example 2

[0109] Figure 2 This is a schematic diagram of a CI / CD build configuration (BuildPipelineConfig) of a configuration architecture language design method according to an embodiment of the present invention.

[0110] like Figure 2 As shown, the method includes the following steps:

[0111] Step 201. Capture requirements for CI / CD system build configuration

[0112] Configure the build process in the CI / CD system, including build steps, platforms, plug-in dependencies, etc., to establish the basic framework.

[0113]

[0114] Step 202. Establish basic version information of the project

[0115] project: string;

[0116] version:string@regex("^v[0-9]+\\.[0-9]+\\.[0-9]+$");

[0117] Step 203. Setting up the platform build step

[0118]

[0119]

[0120] Step 204. Platform settings

[0121]

[0122] Step 205. Plugin settings

[0123]

[0124] Step 206. Output directory constraints

[0125]

[0126] Step 207. Constraints on plugin subsets

[0127]

[0128] Step 208. Configuration for CI / CD system build is complete

[0129] In summary, a pseudo-code example of CI / CD build configuration for a configuration architecture language design method is as follows:

[0130]

[0131]

[0132] All steps are complete, completing a CI / CD build configuration example for a configuration architecture language design method. In this example, the dynamic key ('*') in 'platforms' allows for custom platforms (such as 'ubuntu20', 'win10', etc.); the 'output_dir' constraint must begin with 'build / ' to maintain build product consistency; 'subset(enabled_plugins,plugins,[id])' is used to ensure that enabled plugins are among the defined plugins; and arbitrary environment variable names and contents can be passed within the steps to ensure flexibility.

[0133] In summary, the present invention proposes a configuration architecture language design method, which solves the shortcomings of existing configuration languages ​​(such as JSON Schema, TypeScript) in dynamic structure verification, constraint logic expression, scope isolation and tool chain support, as well as the contradiction between security and efficiency in dynamic configuration scenarios by integrating wildcard dynamic structure with static type verification, local scope constraints, expressive conditional logic, declarative relationship modeling mechanism, "controlled / uncontrolled" strategy, and multiple verification technologies; in addition, CSL is deeply integrated with the tool chain to realize automatic generation of configuration documents, IDE intelligent completion and multi-environment configuration verification, significantly improving the reliability and development efficiency of configuration management. The present invention can be widely used in fields such as microservices and DevOps tool chains, significantly improving the maintainability and development efficiency of configuration, and has high commercial value and technical barriers.

[0134] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, but the scope of protection of the present invention is not limited thereto. Any technician familiar with the field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should all be covered by the scope of protection of the present invention.

Claims

1. A method for designing a Configuration Schema Language (CSL), characterized in that: By integrating wildcard dynamic structures with static type verification, local scope constraints, expressive conditional logic, and declarative relationship modeling, it achieves a balance between flexibility and security. It also clarifies configuration boundaries through a "controlled / uncontrolled" strategy. It supports multiple validation technologies and implements "batch regular expression verification of key names." It also features a rich annotation system and toolchain-friendly design. Based on the captured external usage requirements, the basic architecture of the designed CSL is as follows: / / Root configuration structure config MyAppConfig { / / Basic key-value pairs (required by default) (can be used to verify whether the configuration file is correct) app_name: string; version: string; environment: "dev" | "staging" | "prod" = "dev"; / / optional default value / / Optional key (use '?' to indicate) timeout?: number @min(0) @max(60); / / Verification annotation / / Nested tables database: { host: string; port: number @range(1024, 65535); credentials?: { / / Optional subtable username: string; password: string; }; }; / / Object array endpoints: { path: string; method: "GET" | "POST" | "PUT"; rate_limit?: number; }[]; / / Table / array of unspecified structure / metadata?: any{}; debug_flags?: any[]; / / Nested table with optional unspecified content services: { name: string; config?: any{}; / / Allow any subtable structure }[]; / / Table array of unspecified structure raw_data?: any{}[]; / / Key relationships and constraints constraints { / / 1. Conflict relationship: / / Application of conflict relations to keys of specified structure types: / / 'ssl' and 'insecure_mode' cannot coexist conflicts database.ssl with insecure_mode; / / Application of conflict relations to keys of conflict relations of unspecified structure: / / "debug_flags" and "production_mode" cannot coexist conflicts debug_flags with production_mode; / / 2. Dependency: (conditional dependency) / / Application of dependencies to keys of specified structure types: / / If 'credentials' exists, 'environment' must be "prod" requires database.credentials => environment == "prod"; / / Application of dependencies to keys of unspecified structure types: / / If "metadata" exists, then "version" must exist (value not checked) requires metadata => version; / / As a special case of dependency, mixed dependency is used to describe scenarios with complex dependency conditions: / / If "services" exists, then "app_name" must match the regular expression requires services => app_name @regex("^svc-.*"); / / 3. Custom validation relationship: When 'environment' is "prod", 'timeout' must be greater than 10 validate environment == "prod" ? timeout > 10 : true; }; } 2. The CSL design method according to claim 1, wherein: Integrate wildcard dynamic structure and static type verification mechanism; CSL provides a wildcard key mechanism that allows developers to define sub-configurations with undefined key names but uniform structures. Support type constraints and annotations; You can define local constraints for all wildcard keys; The key name itself can be verified (all_keys(...) match); CSL achieves a balance between concise expression and fine control; 3. The CSL design method according to claim 1, characterized in that: Local scope constraint mechanism; In CSL, each nested level (including wildcard blocks) can have an independent constraints block, which strictly isolates the scope and only acts on the fields of the current level. It does not allow access to upper-level or global fields to prevent global pollution. CSL achieves true scope isolation at the syntax and semantic levels, making constraint logic more intuitive, secure, and easy to maintain, and achieving scope isolation and clear constraint logic.

4. The CSL design method according to claim 1, wherein: Expression-based conditional logic verification mechanism; CSL uses C-style expression syntax (?:, ==, &&, exists(), etc.) to write logical validation statements. CSL's validate function provides programmatic validation capabilities while retaining the simplicity of a Domain-Specific Language (DSL).

5. The CSL design method according to claim 1, characterized in that: Declarative relational modeling; CSL uses a declarative constraint relationship model to express state conflicts and field dependencies in business logic (such as 'conflicts' and 'requires'); Compared to the lengthy nested structure of JSON Schema, CSL provides a language-level mechanism with clear semantics and neat structure. Improve maintainability and IDE support (clear relationships, easy automatic prompts and verification); 6. The CSL design method according to claim 1, characterized in that: "controlled / uncontrolled" strategy; In CSL, the "controlled / uncontrolled" strategy for any{} and any[] is as follows: Explicitly allow uncontrolled structures (any{} / any[]); Restrictions cannot be nested; IDE tools need to prompt warnings (flexible design: tolerant during development, vigilant in production); CSL clarifies configuration boundaries through explicit settings, avoiding the semantic ambiguity of 'additionalProperties: true' in JSON Schema; 7. The CSL design method according to claim 1, characterized in that: Support multiple verification technologies; CSL supports subset validation ('subset' function) and batch key validation ('all_keys', etc.) with explicit syntax support, ensuring transparency and controllability of business rules (such as plugin validity checks); Among them, subset verification is used to verify the inclusion relationship between arrays (or object arrays), allowing comparison keys to be set through properties to achieve flexible comparison of object arrays; Batch key verification, through count_keys(), all_keys(), wildcard_keys() and match, start_with, contains, etc., to verify structural rules and implement "batch regular expression verification of key names"; in: count_keys(table) – returns the number of keys in the table; all_keys(table) – gets all key names for validation; wildcard_keys(table) – get all wildcard key names; match "^[az]+$" – checks if the key name matches a regular expression; start_with "prefix_", end_with "_suffix", contain "temp" – check whether the key name string meets the rules; 8. The CSL design method according to claim 1, wherein: Rich annotation system and tool chain-friendly design; CSL significantly improves development efficiency through a rich annotation system (such as `@min` and `@regex`) and toolchain-friendly design; The annotation system can add annotations to fields, provide type-level restrictions, and make constraints intuitive and reusable. The full language structure design is tool-chain friendly and declaration-driven, focusing on parsability and generability, supporting LSP / IDE automatic prompts, document generation and pre-deployment verification, automatically deducing type trees, generating documents or code templates, and taking into account both "machine-friendliness" and "human-friendliness".

Images