+ 
+
+ 
\ No newline at end of file
diff --git a/doc/public/articles/components/index.html b/doc/public/articles/components/index.html
index 0488fb1..28cec96 100644
--- a/doc/public/articles/components/index.html
+++ b/doc/public/articles/components/index.html
@@ -1,9 +1,9 @@
-
-
-
+
+
+
-The date-time data type serves as the parent data type for both date and time types. It is a subtype of JSON string type and thus formatted as per the JSON string specification. It is not intended to be used directly in a schema, but it provides common functionality for both date and time types.
#datetime
The date data type accepts a string representation of a date, conforming to the ISO 8601 standard (date part only). This is the default configuration, which can be modified using the directive described here. It is a subtype of date-time type and thus also formatted as per the JSON string specification. Detailed explanations of the ISO 8601 standard can be found in this document. Furthermore, you can refer to this document for a detailed description of the date pattern associated with this data type. To define this data type in schema, use the following syntax:
+The date data type accepts a string representation of a date, conforming to the ISO 8601 standard (date part only). This is the default configuration, which can be modified using the directive described here. It is a subtype of date-time type and thus also formatted as per the JSON string specification. Detailed explanations of the ISO 8601 standard can be found in this document. Furthermore, you can refer to this document for a detailed description of the date pattern associated with this data type. To define this data type in schema, use the following syntax:
#date
The time data type accepts a string representation of a time (including both date and time parts), in accordance with the ISO 8601 standard. This default configuration can be modified using the directive described here. Similar to the date data type, it is a subtype of date-time data type and thus also formatted as per the JSON string specification. Here is the ISO 8601 standard document, which contains detailed explanations. Furthermore, you can refer to this document for a detailed description of the date-time pattern associated with this data type. To define this data type in schema, use the following syntax:
+The time data type accepts a string representation of a time (including both date and time parts), in accordance with the ISO 8601 standard. This default configuration can be modified using the directive described here. Similar to the date data type, it is a subtype of date-time data type and thus also formatted as per the JSON string specification. Here is the ISO 8601 standard document, which contains detailed explanations. Furthermore, you can refer to this document for a detailed description of the date-time pattern associated with this data type. To define this data type in schema, use the following syntax:
#time
The number data type serves as the parent data type for all numeric types accommodated by the schema, including integer, floating-point, and exponent-based numbers. It accepts any JSON numerical value in accordance with the JSON standard. The syntax for specifying the number type is as follows:
diff --git a/doc/public/articles/datetime/index.html b/doc/public/articles/datetime/index.html index 9af493d..f105599 100644 --- a/doc/public/articles/datetime/index.html +++ b/doc/public/articles/datetime/index.html @@ -1,9 +1,9 @@ - - - + + + -The default value of this directive is false, which means that by default, undefined properties in the JSON document are not ignored, and validation errors will be raised for them. For example, the following usage of this directive instructs the validation process to ignore any undefined properties in the JSON document:
%pragma IgnoreUndefinedProperties: true
The DateDataTypeFormat pragma directive enables you to customize the default format of the #date data type. By default, the #date data type follows the ISO 8601 standard, precisely using the format YYYY-MM-DD. Additional details on date-time patterns and formats are available here. The subsequent example illustrates the process of defining a customized date format for the #date data type:
The DateDataTypeFormat pragma directive enables you to customize the default format of the #date data type. By default, the #date data type follows the ISO 8601 standard, precisely using the format YYYY-MM-DD. Additional details on date-time patterns and formats are available here. The subsequent example illustrates the process of defining a customized date format for the #date data type:
%pragma DateDataTypeFormat: "DD-MM-YYYY"
To customize the default format of the #time data type, utilize the TimeDataTypeFormat pragma directive. By default, the #time data type follows the ISO 8601 standard, precisely in the format YYYY-MM-DD'T'hh:mm:ss.FZZ. Further information on date-time patterns and formats can be found here. The following example demonstrates how to specify a customized time format for the #time data type:
To customize the default format of the #time data type, utilize the TimeDataTypeFormat pragma directive. By default, the #time data type follows the ISO 8601 standard, precisely in the format YYYY-MM-DD'T'hh:mm:ss.FZZ. Further information on date-time patterns and formats can be found here. The following example demonstrates how to specify a customized time format for the #time data type:
%pragma TimeDataTypeFormat: "DD-MM-YYYY hh:mm:ss"
The FloatingPointTolerance pragma directive allows you to define the tolerance level for relative errors in floating-point numbers during calculations and computations carried out by the validation process. By default, this directive is set to 1E-10, indicating a small tolerance. However, you have the flexibility to adjust this value to any desired number. To specify a custom tolerance value of 1E-07, you can use the following notation as an example:
%pragma IgnoreObjectPropertyOrder: false
This feature in JSON schemas allows you to define a name for a component or fragment of schema or validation rules, which can be referenced from various parts of your schema. This means that if you encounter similar validation requirements in different sections of your schema, you can conveniently refer to the named component instead of duplicating the same validation rules.
-By providing clear and descriptive names for these validation rules or sub-schemas, you can enhance the overall clarity and context of your schema. This clarity not only makes it easier to understand the structure and intent of the schema but also contributes to keeping your complex schema well-organized, concise, and more manageable. For more information about the schema component syntax and format, please refer to the documentation here.
+By providing clear and descriptive names for these validation rules or sub-schemas, you can enhance the overall clarity and context of your schema. This clarity not only makes it easier to understand the structure and intent of the schema but also contributes to keeping your complex schema well-organized, concise, and more manageable. For more information about the schema component syntax and format, please refer to the documentation here.
The name or alias of the directive is always start with $ which also refers to that they are named fragment defined elsewhere in the schema. Here is a simple example of how to use this directive:
%define $product: {
"id": @length(2, 10) @regex("[a-z][a-z0-9]+") #string,
diff --git a/doc/public/articles/functions/index.html b/doc/public/articles/functions/index.html
index 043695a..f7638f0 100644
--- a/doc/public/articles/functions/index.html
+++ b/doc/public/articles/functions/index.html
@@ -1,9 +1,9 @@
-
-
-
+
+
+
-
+
Validates whether the target string is a valid phone number. It follows the ITU-T E.163 and E.164 telephone number notation to determine the validity of the phone number. In addition to conforming to this standard, it recognizes all widely used national and international phone number formats, ensuring compatibility with a wide range of systems and user requirements.
#string target - @date(pattern)
-Validates that the target string matches the date and time pattern specified by the pattern parameter. It fully supports the ISO 8601 date and time format. Beyond this standard, it also allows custom date and time formats, ensuring compatibility with various systems and meeting diverse users and businesses requirements. This document provides a comprehensive overview of the date-time custom patterns.
Validates that the target string matches the date and time pattern specified by the pattern parameter. It fully supports the ISO 8601 date and time format. Beyond this standard, it also allows custom date and time formats, ensuring compatibility with various systems and meeting diverse users and businesses requirements. This document provides a comprehensive overview of the date-time custom patterns.
#string target - @time(pattern)
-Both the @date and @time functions support a complete range of date-time patterns, enabling the precise definition of any date and time scenario. Therefore, these functions can be used interchangeably. When the sole consideration is the date or day of the month in a year, employing the @date function is the more convenient choice. In contrast, when it becomes necessary to specify a particular time on a date, the @time function is the more appropriate option. To learn more about date-time patterns, please refer to this page.
Both the @date and @time functions support a complete range of date-time patterns, enabling the precise definition of any date and time scenario. Therefore, these functions can be used interchangeably. When the sole consideration is the date or day of the month in a year, employing the @date function is the more convenient choice. In contrast, when it becomes necessary to specify a particular time on a date, the @time function is the more appropriate option. To learn more about date-time patterns, please refer to this page.
#datetime target - @range(#string start, #string end)
Validates that the target date-time satisfies the range requirement specified by the parameters. It checks that the target date-time is from or after the start date-time specified and simultaneously until and before the end date-time specified. If not, a validation error will generate. The start and end parameters must be the string representation of the target data type, which can either be a #date or #time type.
| Introduction | +Introduction | |
| Quick Start | +Quick Start | |
| Validation Syntax | +Validation Syntax | |
| Directives | +Directives | |
| Specification | +Specification | |
| Data Types | +Data Types | |
| Functions | +Functions | |
| Date and Time | +Date and Time | |
| Components | +Components | |
| Source Build | +Source Build |