Update project documentations

README.md

@@ -4,7 +4,7 @@ A JSON Schema is crucial for making communication, interoperability, validation,
 ## Design Goals
 The traditional standard JSON Schema rigorously follows the conventional JSON structure, which unfortunately comes at the expense of simplicity, conciseness, and readability. Our goal is to develop a new JSON Schema that promotes these essential aspects that were previously missing.
 
-This new schema is simple, lucid, easy to grasp, and doesn't require much prior knowledge to understand it. It also offers a shallow learning curve for both reading and writing. Additionally, its simplicity and conciseness allow us and machines to read-write more efficiently. Moreover, a large set of constraint data types and functions within the core schema facilitates the precise definition of JSON documents, significantly reducing the potential for communication gaps among collaborators. Furthermore, its inherent extensibility simplifies the process of integrating new constraints and functionalities to meet the diverse requirements of modern web services.
+This new schema is simple, lucid, easy to grasp, and doesn't require much prior knowledge to understand it. It also offers a shallow learning curve for both reading and writing. Additionally, its simplicity and conciseness allow us and machines to read-write more efficiently. Moreover, a large set of constraint data types and functions within the core schema promotes the precise definition of JSON documents, significantly reducing the potential for communication gaps among collaborators. Furthermore, its inherent extensibility not only facilitates the test automation process in API testing but also simplifies the integrations of new constraints and functionalities to meet the diverse requirements of modern web services.
 
 ## Basic Example
 Let's explore an example of our schema for a typical JSON API response containing information about a user profile or account. The schema is very self-explanatory and thus almost no prior knowledge is required to understand the schema and the JSON responses specified by this schema.
@@ -220,4 +220,4 @@ The subsequent JSON sample is an illustrative example that successfully validate
     }
 }
 ```
-For more information about the schema syntax format and library functionalities, please refer to the reference documentation [here](https://relogiclabs.github.io/JsonSchema-Java/api/index.html).
+For more information about the schema syntax format and library functionalities, please refer to the reference documentation [here](https://relogiclabs.github.io/JsonSchema-Java/api/index.html).

doc/archetypes/default.md

@@ -0,0 +1,5 @@
++++
+title = '{{ replace .File.ContentBaseName "-" " " | title }}'
+date = {{ .Date }}
+draft = true
++++

doc/content/_index.md

@@ -0,0 +1,11 @@
++++
+title = 'New Json Schema'
+date = 2023-10-08T09:38:53+06:00
++++
+
+# New Json Schema
+The New JSON Schema prioritizes simplicity, conciseness, and readability, making it user-friendly and accessible without the need for extensive prior knowledge. It offers efficient read-write facilities, precise JSON document definition through various data types and functions, and extensibility to meet modern web service diverse requirements. For a comprehensive overview of this JSON Schema, we invite you to explore our dedicated post available [here](https://www.relogiclabs.com/p/json-schema.html).
+
+<div class="banner-image">
+    <img src="/images/json-schema.webp" alt="New Json Schema">
+</div>

doc/content/articles/_index.md

@@ -0,0 +1,6 @@
++++
+title = 'Articles'
+date = 2023-10-08T09:38:53+06:00
++++
+
+The New JSON Schema prioritizes simplicity, conciseness, and readability, making it user-friendly and accessible without the need for extensive prior knowledge. It offers efficient read-write facilities, precise JSON document definition through various data types and functions, and extensibility to meet modern web service diverse requirements.

doc/content/articles/datatypes.md

@@ -0,0 +1,106 @@
++++
+title = 'Data Types'
+date = 2023-10-08T09:38:53+06:00
+weight = 6
++++
+
+<style>
+pre code { font-size: 1.1em; }
+</style>
+
+# Constraint Data Types
+Data types play a pivotal role in validating JSON data for compliance with the schema. Essentially, data types determine the kind of data that a JSON element or value can contain. This mechanism serves as a fundamental process in maintaining the accuracy, consistency, and integrity of JSON document and its structure throughout the system, where data quality and reliability are vital.
+
+In the schema document, data types are denoted by the `#` prefix. Here is an outline of all data types, including their subtypes, used in the schema document to validate a JSON document. When using multiple data types for validation, it indicates that the JSON value is considered valid if it complies with any of the specified alternative data types. All of these data types and their subtypes offer the flexibility of selecting the most appropriate type based on requirements.
+
+```html
+#any
+ ┬
+ ├ #object
+ ├ #array
+ ├ #string
+ │  ┬
+ │  ├ #date
+ │  └ #time
+ ├ #number
+ │  ┬
+ │  ├ #integer
+ │  ├ #float
+ │  └ #double  
+ ├ #boolean
+ └ #null
+```
+
+### The Any Data Type
+This data type accepts any valid JSON value that conforms to the JSON standard. It is the least restrictive data type and serves as the parent type for all other data types defined in this schema, each of which imposes more specific constraints. Here is the [specification](https://www.json.org) of JSON document containing rules of all valid JSON values. Following is the syntax for specifying this data type:
+```html
+#any
+```
+
+### The Object Data Type
+This data type represents the JSON object type and accepts any JSON object specified by the JSON standard. The specification document for JSON provides details about the different syntax and forms of JSON objects. Following is the syntax for specifying this data type:
+```html
+#object
+```
+
+### The Array Data Type
+This data type represents the JSON array type and accepts any JSON array specified by the JSON standard. The specification document for JSON provides details about the various syntax and forms of JSON arrays. Below is the syntax for specifying this data type:
+```html
+#array
+```
+
+### The String Data Type
+This is one of the most commonly used data types in a JSON document, designed to accept any JSON string as specified by the JSON standard. The syntax for specifying this data type is as follows:
+```html
+#string
+```
+
+### The Date Data Type
+The date data type accepts only a type of string which represent a date specified by ISO 8601 standard (date part only). It is a subtype of string data type and thus formatted as per the JSON string specification. Detailed explanations of the ISO 8601 standard can be found in this [document](https://www.iso.org/iso-8601-date-and-time-format.html). Furthermore, you can refer to this [document](/JsonSchema-DotNet/articles/datetime.html) for a detailed description of the date pattern associated with this data type. To define this data type in schema, use the following syntax:
+```html
+#date
+```
+
+### The Time Data Type
+The time data type only accepts strings representing date-time (including both date and time), in accordance with the ISO 8601 standard. Similar to the date data type, it is a subtype of string data type and thus formatted as per the JSON string specification. Here is the ISO 8601 standard [document](https://www.iso.org/iso-8601-date-and-time-format.html), which contains detailed explanations. Furthermore, you can refer to this [document](/JsonSchema-DotNet/articles/datetime.html) 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:
+```html
+#time
+```
+
+### The Number Data Type
+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:
+```html
+#number
+```
+
+### The Integer Data Type
+The integer data type is a subtype of the number data type that only allows integral numbers or whole numbers without any fraction and exponent and thus provides constraints for a wide range of real-world scenarios where numbers cannot involve decimal points or exponents. To specify the integer type in schema, use the following syntax:
+```html
+#integer
+```
+
+### The Float Data Type
+The float data type is also a subtype of the number data type that only accepts floating point numbers and does not allow exponent in numbers or integral numbers. This constraint is useful for various real-world applications that require numbers to be exclusively in floating-point format. To specify the float type in schema, use the following syntax:
+```html
+#float
+```
+
+### The Double Data Type
+The double data type, as a subtype of the number data type, exclusively accepts numbers with exponents. It can either be an integral number with an exponent or a floating-point number with an exponent. This constraint distinguishes it from other number formats and makes it particularly useful for handling large numbers with exponents. To specify the double type in a schema, use the following syntax:
+```html
+#double
+```
+
+### The Boolean Data Type
+The boolean data type is a binary or switch-based data type that only accepts two values, namely `true` and `false`. It is particularly useful in situations where toggling and switching are necessary. To specify the boolean type in the schema, use the following syntax:
+```html
+#boolean
+```
+
+### The Null Data Type
+The null data type serves as a special constraint within JSON schemas, facilitating the controlled use of `null` in place of other JSON elements or values. Typically, it is combined with other data types to permit the use of `null` for specific JSON elements or values. This can set constraints for scenarios in which an array without any elements and an object without any properties can either have `null` or only be allowed to be empty. 
+
+Additionally, the `@nonempty` constraint functions can be employed to further control the use of empty values within a JSON document. To specify the null type in the schema, use the following syntax:
+```html
+#null
+```

doc/content/articles/datetime.md

@@ -0,0 +1,56 @@
++++
+title = 'Date and Time'
+date = 2023-10-08T09:38:53+06:00
+weight = 8
++++
+
+# Date and Time Patterns
+Dates and times are fundamental data types used in a wide range of data exchange scenarios. This schema offers a comprehensive set of tools for managing dates and times, including pattern-based formatting to meet the unique requirements of various systems and applications. Simultaneously, it incorporates validation processes to ensure compliance with the schema.
+
+Date and time formats are defined using date and time pattern strings. Within these pattern strings, unquoted letters ranging from 'A' to 'Z' and 'a' to 'z' serve as placeholders representing various components of a date or time string. To prevent their interpretation as patterns, text can be enclosed in single quotes ('). Additionally, two consecutive single quotes ('') are used to represent a literal single quote within the string. Any characters outside of these uppercase and lowercase letters, as well as the text enclosed in single quotes, are not interpreted and are matched against the input string during validation.
+
+Below, you will find a list of pattern letters and strings that are defined for date and time patterns. Please note that any characters within the 'A' to 'Z' and 'a' to 'z' range are reserved and should not be directly included in the pattern string.
+
+| Pattern | Description                           | Example |
+|---------|---------------------------------------|---------|
+| G       | Era period designator                 | AD      |
+| YYYY    | Four digit year number                | 1970    |
+| YY      | Two digit year number                 | 70      |
+| MM      | Month number in year (2 digit form)   | 01      |
+| MMMM    | Full name of month                    | January |
+| MMM     | Short name of month                   | Jan     |
+| M       | Month number in year (1-2 digit form) | 1, 01   |
+| DDDD    | Full name of day in week              | Monday  |
+| DDD     | Short name of day in week             | Mon     |
+| DD      | Day in month (2 digit form)           | 01      |
+| D       | Day in month (1-2 digit form)         | 1, 01   |
+| t       | AM/PM designator                      | AM, PM  |
+| hh      | Hour in day (2 digit form)            | 01, 12  |
+| h       | Hour in day (1-2 digit form)          | 1, 01   |
+| mm      | Minute in hour (2 digit form)         | 01, 20  |
+| m       | Minute in hour (1-2 digit form)       | 1, 01   |
+| ss      | Second in minute (2 digit form)       | 1, 01   |
+| s       | Second in minute (1-2 digit form)     | 1, 01   |
+| f       | Tenths of a second                    | 1       |
+| ff      | Hundredths of a second                | 11      |
+| fff     | Milliseconds of a second              | 111     |
+| ffff    | Ten thousandths of a second           | 1111    |
+| fffff   | Hundred thousandths of a second       | 11111   |
+| ffffff  | Millionths of a second                | 111111  |
+| F       | Fraction of a second upto 6 digits    | 1, 111  |
+
+The pattern components listed above can be combined to create comprehensive and customized date and time patterns to accommodate all system and user requirements. The following table illustrates some examples of how different date-time pattern components can be combined.
+
+| Combined Pattern            | Example                       |
+|-----------------------------|-------------------------------|
+| YYYY-MM-DD                  | 2023-09-01                    |
+| YYYY-MM-DD'T'hh:mm:ss.fffZZ | 2023-09-01T14:35:10.123+06:00 |
+| MMMM DD, YYYY G             | January 01, 1980 AD           |
+| DDDD, D MMMM YYYY           | Tuesday, 11 July 2023         |
+| YYYY.MM.DD hh.mm.ss t       | 1980.11.21 10.30.50 pm        |
+| DDD, D MMM YY hh:mm:ss ZZ   | Sun, 4 Jul 99 12:08:56 -06:00 |
+| hh:mm:ss t ZZ               | 03:11:30 AM +06:00            |
+
+The first pattern in the table above adheres to the ISO 8601 date format and is used to validate the `#date` data type within the schema. The second pattern in the table follows the ISO 8601 format for date and time, validating the `#time` data type in the schema. Instead of explicitly specifying these patterns in the `@date` or `@time` functions, a more concise approach is to directly utilize the `#date` or `#time` type within the schema.
+
+When the AM/PM designator is included in the date and time pattern, the presence of any hour format specifier indicates that the time is in the 12-hour clock format. Conversely, when the AM/PM designator is omitted, the presence of any hour format specifier indicates that the time is in the 24-hour clock format.