You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -140,20 +142,21 @@ The next example represents an expanded version of the previous one, which bring
140
142
if(role == "user" && target > 5) return fail(
141
143
"ERRACCESS01", "Data access incompatible with 'user' role",
142
144
expected("an access at most 5 for 'user' role"),
143
-
actual("found access " + target + " which is greater than 5"));
145
+
actual("found access " + target + " that is greater than 5"));
144
146
}
145
147
}
146
148
```
147
149
The subsequent JSON sample is an illustrative example that successfully validates against the expanded schema mentioned earlier. Within this example, recurring JSON structures appear that can be validated by defining components or nested functions and data types. Besides, reusing simple component definitions, you can achieve a clear and concise schema when validating large JSON with repetitive structures. This improves the overall readability and maintainability of the schema.
148
150
```json
149
151
{
150
152
"user": {
151
-
"id": 1234,
153
+
"id": 1111,
152
154
"username": "johndoe",
153
155
"role": "admin",
154
156
"isActive": true,
155
157
"registeredAt": "06-09-2023 15:10:30",
156
158
"dataAccess": 10,
159
+
"ipAddress": "127.0.0.1",
157
160
"profile": {
158
161
"firstName": "John",
159
162
"lastName": "Doe",
@@ -183,7 +186,7 @@ The subsequent JSON sample is an illustrative example that successfully validate
183
186
"title": "Working with JSON in Java",
184
187
"content": "Java provides great support for working with JSON...",
Copy file name to clipboardExpand all lines: doc/content/articles/components.md
+9-8
Original file line number
Diff line number
Diff line change
@@ -7,24 +7,25 @@ weight = 10
7
7
# Schema Components
8
8
A schema component, also known as a reusable schema fragment or sub-schema, plays a vital role in improving readability, reducing redundancy, and organizing the structure of a Schema document. In JSON validation, a schema component or fragment defines a validation rule that can be recursively composed of multiple nested validation rules, collectively specifying the expected and valid format of a JSON construct.
9
9
10
-
These schema components are used as an extension of data type validation, as core data types have limited features to validate the internal structure of a composite JSON value or construct. Therefore, a data type is parameterized with a schema component to validate the internal structure of such composite JSON constructs.
10
+
These schema components are used as an extension of data type validation, as core data types have limited features to validate the internal structure of a composite JSON value or construct. Therefore, a data type is parameterized with a schema component to validate the internal structure of such composite JSON constructs.
11
11
12
-
The name or alias of a schema component always starts with `$` which also refers to the fact that they are named schema components or fragments defined elsewhere in the schema. Schema components can be referenced from any other part of the schema document, effectively reducing redundancy and enhancing reusability and readability. The following example defines a simple schema component named `$component` where the validation rule describes an object structure with two key-value pairs:
12
+
The name or alias of a schema component always starts with `$` which unambiguously indicates that they are named schema components or fragments defined elsewhere in the schema. Schema components can be referenced from any parts of the schema document, effectively reducing redundancy and enhancing reusability and readability. The following example defines a simple schema component named `$component` where the validation rule describes an object structure with two key-value pairs:
A composite JSON construct is created by combining multiple values as defined by the JSON specification. These nested values can range from simple, like numbers or strings, to more complex, such as arrays or objects. While simple nested values of a composite construct can be validated using only nested data types and functions, handling hierarchical composite constructs with multiple layers of nested structures requires defining schema components.
18
18
19
-
The second and third rows of the following table illustrate how the component validates the value associated with the data type for which it is used as a parameter. If the associated data type is direct, the component validates the target value itself. Conversely, if the associated data type is nested, the component validates each of the nested values comprising the composite target construct.
19
+
The second and third rows of the following table illustrate how the component validates the value associated with the data type for which it is used as a parameter. If the associated data type is direct, the component validates the target value itself. Conversely, if the associated data type is nested, the component validates each of the nested values.
In the above table, all three rows have identical validation constraints for the input JSON array. This demonstrates that when dealing with simple and primitive nested values in a composite JSON construct, preferring the nested data types and functions is more convenient due to their simplicity and conciseness. However, in cases where the nested values are complex and composite, the schema component syntax becomes more suitable. The following example illustrates how the component syntax can be used to validate elements of a JSON array that are not as straightforward as the previous examples:
28
+
In the above table, all four rows have identical validation constraints for the input JSON array. This demonstrates that when dealing with simple and primitive nested values in a composite JSON construct, preferring the nested data types and functions is more convenient due to their simplicity and conciseness. However, in cases where the nested values are complex and composite, the schema component syntax becomes more suitable. The following example illustrates how the component syntax can be used to validate elements of a JSON array that are not as straightforward as the previous examples:
28
29
```js
29
30
%define $article: {
30
31
"id": @range(1, 100) #integer,
@@ -36,7 +37,7 @@ In the above table, all three rows have identical validation constraints for the
36
37
%schema: @length(1, 10) #object*($article) #array
37
38
```
38
39
39
-
In practical scenarios, JSON arrays often hold multiple composite JSON constructs as elements, typically sharing a recurring pattern and structure similar to the example above. To facilitate the validation of such elements, using schema components is highly effective.
40
+
In practical scenarios, JSON arrays often hold multiple composite JSON constructs as elements, typically sharing a recurring pattern and structure similar to the example above. To facilitate the validation of such elements, using schema components is highly effective.
40
41
41
42
By defining a reusable schema component with a clear and descriptive name, one can improve the overall clarity and readability of the Schema document with recurring structures. 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 instance, consider the following example of a JSON document which is valid against the schema example provided above, demonstrating the usage of a schema component:
Copy file name to clipboardExpand all lines: doc/content/articles/cscript.md
+14-14
Original file line number
Diff line number
Diff line change
@@ -49,20 +49,20 @@ The `#void` type is reserved for internal operations, including initializing una
49
49
## Operators & Precedences
50
50
CScript operators are symbols that are used to perform operations on variables and values. The direct operation of any operator that requires a modifiable l-value including `++`, `--` or `=` will raise an exception for the readonly schema nodes. The following table lists the operators according to their precedences from the highest to the lowest:
Function types are essential for specifying the executable units that serve as the building-blocks of validation process within CScript. All function types can also accept variable number of arguments, specified by an ellipsis `...` after the last parameter name which is then bound to an array containing the remaining arguments.
Copy file name to clipboardExpand all lines: doc/content/articles/directives.md
+14-2
Original file line number
Diff line number
Diff line change
@@ -55,7 +55,7 @@ To customize the default format of the `#time` data type, utilize the `TimeDataT
55
55
```
56
56
57
57
### Floating Point Tolerance
58
-
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:
58
+
The pragma directive`FloatingPointTolerance` 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:
59
59
```js
60
60
%pragma FloatingPointTolerance:1E-07
61
61
```
@@ -66,6 +66,18 @@ The `IgnoreObjectPropertyOrder` pragma directive provides a means to enforce a s
66
66
%pragma IgnoreObjectPropertyOrder:false
67
67
```
68
68
69
+
### Enable Contextual Exception
70
+
The `EnableContextualException` pragma directive enables an additional type of exception. These exceptions provide supplementary contextual information about the primary exceptions, showing the errors that occurred during the validation process. The default value of this directive is `false`, meaning no contextual exceptions are generated.
71
+
```js
72
+
%pragma EnableContextualException:true
73
+
```
74
+
75
+
### Outline Maximum Length
76
+
The pragma directive `OutlineMaximumLength` specifies the maximum length of tree outlines generated when string representations of large Schema and JSON trees or subtrees are needed. The default maximum length is `200` characters. If the tree or subtree string exceeds this limit, an outline is shown instead of the full string representation. Currently, a basic abbreviation rule is used to create the tree outlines.
77
+
```js
78
+
%pragma OutlineMaximumLength:500
79
+
```
80
+
69
81
## Definition / Define Directive
70
82
This feature in JSchema allows you to define a name for a schema component or fragment, 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 schema component instead of duplicating the same validation rules. For more information about the schema component syntax and format, please refer to the documentation [here](/JSchema-Java/articles/components). Here is a simple example of how to use this directive:
71
83
```js
@@ -102,7 +114,7 @@ The script directive enables the inclusion of CScript code into a JSchema docume
102
114
%script: {
103
115
constraint functioncheckAccess(role) {
104
116
if(role[0] =="user"&& target >5) returnfail(
105
-
"ERRACCESS01", "Data access incompatible with 'user' role",
117
+
"EX_ERRACCESS01", "Data access incompatible with 'user' role",
106
118
expected("an access at most 5 for 'user' role"),
107
119
actual("found access "+ target +" which is greater than 5"));
0 commit comments