Introduction
This is the 8th installment of my XML Workshop which aims at explaining the details of working with XML in TSQL. You can find the the other articles in this series here. In the previous articles, we have seen how to read values from XML variables and columns, generate XML structures using FOR XML with AUTO, RAW, PATH and EXPLICIT.
The last two articles were focusing on TYPED XML and had been explaining how to generate an XML schema that can be used to validate the XML data. We have seen how to validate the existence of elements and attributes, how to validate data types and how to apply restrictions on the actual data.
XML Schemas usually are very complex and confusing. The more validation and rules you apply, the more complex the schema will become. This article will present a couple of approaches that will help you to make your schemas less complex and easier to read and understand.
Creating Custom Types
One of the ways to simplify your schema is by using Custom Types. If an element is having very complex validation rules, it will make more sense to move it to a Custom Type and then add an element of the custom type in the schema definition. Custom types are more useful when you need to reuse the validations on different elements. For example, the validation for Phone number can be used for other elements like Phone-Home, Phone-Office, Fax etc.
Let us look at an example which uses a custom type. I am updating the XML schema that we used in the previous example. The new version of the XML schema has a Custom Type: AgeType. Note that the validation rules do not change. The XML structure expected by the schema is the same. What we changed is only the way we defined it. [See sql1.sql and schema1.xml in thecode download]
1 DROP XML SCHEMA COLLECTION EmployeeSchema
2 GO
3 /*
4 A schema may look very complex if there are lots of elements,
5 validations and restrictions. Many of the schemas that you might
6 use in a production environment would be very long and complex.
7
8 To simplify the schema development and to make it easier to understand
9 and manage, you can define your own custom types. These types can be used
10 as children of a "complexType".
11
12 The following example is using the Schema that we defined in the previous
13 session. I have modified the previous schema, to demonstrate the usage of
14 a custom type. In this version, I have defined a type named "AgeType".
15 You can find the definition of the type at the bottom of the schema definition.
16 Note that I have defined an element which is of type "AgeType" in the schema
17 definition.
18
19 Use of custom "types" will make the schema development simpler and easier.
20 It helps you to re-use the validation rules defined, in multiple instances
21 of the type.
22 */
23 CREATE XML SCHEMA COLLECTION EmployeeSchema AS '
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79 '
80 GO
81
82 /*
83 The following is a correct XML value that validates with the above SCHEMA. The
84 XML value is the same that we used in the previous session. The only change
85 that we did in this version is a restructuring of the schema, which does not
86 affect the validation rules.
87 */
88 DECLARE @emp AS XML(EmployeeSchema)
89 SET @emp = '
90
91
92
93
94
95
96
97 '
Probably it might be a good idea to move all the elements that we have to Custom Types. Let us do it. [ see sql2.sql andschema2.xml in the code download]
1 DROP XML SCHEMA COLLECTION EmployeeSchema
2 GO
3 /*
4 Here is the final version of the schema. I have broken all the elements into various
5 custom types.
6 */
7 CREATE XML SCHEMA COLLECTION EmployeeSchema AS '
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 '
59 GO
60
61 /*
62 The following is a correct XML value that validates with the above SCHEMA. Note
63 that the changes in the schema structure did not affect the validation rules.
64 */
65 DECLARE @emp AS XML(EmployeeSchema)
66 SET @emp = '
67
68
69
70
71
72
73
74 '
Inheriting from a Custom Type
Anyone who understands OOPS would also understand the power and freedom that inheritance can give to a class. It is the same with Custom Types in a SCHEMA definition. It supports inheritance. You can derive other custom types from a parent type. Use of inheritance can make your SCHEMA definition even simpler and easier to understand. I have put up a quick example that shows how to inherit from a Custom Type within a Schema definition.[ See sql3.sql and schema3.xml in the code download]
1 DROP XML SCHEMA COLLECTION EmployeeSchema
2 GO
3 /*
4 We have just seen how to define custom types. This example explains
5 how to create a derived type which inherits the rules defined in a parent
6 type.
7
8 The following SCHEMA defines a type "EmployeeType". "ProjectManagerType"
9 and "SupportEngineerType" inherit from "EmployeeType". Each of the
10 derived types has their own elements and can have own validation rules.
11 All the elements, properties and validation rules defined in the parent
12 type will be available to the derived type too.
13 */
14 CREATE XML SCHEMA COLLECTION EmployeeSchema AS '
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53 '
54 GO
55
56 /*
57 Here is the XML that validates with the above schema. Note that we have
58 two elements: ProjectManager and SupportEngineer. Both of them have all
59 the elements defined in the EmployeeType: FullName, Department and
60 ReportsTo.
61 */
62
63 DECLARE @emp AS XML(EmployeeSchema)
64 SET @emp = '
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82 '
Conclusions
This article explains how to create custom types and create types that inherit from other types. Usage of custom types can make the XML schema less complex and easier to understand and manage.