1 00:00:00,430 --> 00:00:03,000 In this video, we'll see a demonstration of JSON data. 2 00:00:04,120 --> 00:00:05,530 As a reminder, JSON stands for 3 00:00:05,750 --> 00:00:08,060 Java Script Object Notation, and 4 00:00:08,200 --> 00:00:09,450 it's a standard for writing 5 00:00:09,770 --> 00:00:12,980 data objects into human readable format, typically in a file. 6 00:00:13,810 --> 00:00:15,690 It's useful for exchanging data 7 00:00:16,070 --> 00:00:17,680 between programs, and generally 8 00:00:18,110 --> 00:00:19,780 because it's quite flexible, it's useful 9 00:00:20,070 --> 00:00:22,510 for representing and for storing data that's semi-structured. 10 00:00:23,120 --> 00:00:24,740 A reminder of the 11 00:00:24,820 --> 00:00:26,690 basic constructs in JSON, we 12 00:00:26,870 --> 00:00:28,080 have the atomic value, such 13 00:00:28,300 --> 00:00:29,790 as integers and strings and so on. 14 00:00:30,320 --> 00:00:31,280 And then we have two types of 15 00:00:31,660 --> 00:00:32,730 composite things; we have 16 00:00:33,150 --> 00:00:34,120 objects that are sets of 17 00:00:34,200 --> 00:00:37,270 label-value pairs and then we have arrays that are lists of values. 18 00:00:38,480 --> 00:00:40,140 In the demonstration, we'll go through 19 00:00:40,280 --> 00:00:41,740 in more detail the basic constructs 20 00:00:41,860 --> 00:00:43,890 of JSON and we'll look at 21 00:00:44,010 --> 00:00:45,830 some tactic correctness, we'll demonstrate 22 00:00:46,340 --> 00:00:47,620 the flexibility of the data 23 00:00:47,900 --> 00:00:48,950 model and then we'll 24 00:00:49,180 --> 00:00:50,580 look briefly at JSON's schema, 25 00:00:50,930 --> 00:00:52,510 not widely used yet but 26 00:00:52,810 --> 00:00:54,200 still fairly interesting to look at 27 00:00:54,290 --> 00:00:55,200 and we'll look at some validation 28 00:00:55,920 --> 00:00:57,740 of JSON data against a particular schema. 29 00:00:59,380 --> 00:01:00,560 So, here's the JSON 30 00:01:00,620 --> 00:01:02,570 data that we're gonna be working with during this demo. 31 00:01:03,020 --> 00:01:04,250 It's the same data that appeared 32 00:01:04,720 --> 00:01:06,480 in the slides, in the introduction 33 00:01:07,020 --> 00:01:08,040 to JSON, but now we're going 34 00:01:08,380 --> 00:01:10,710 to look into the components of the data. 35 00:01:11,800 --> 00:01:12,700 It's also by the way, the 36 00:01:13,210 --> 00:01:14,600 same example pretty much that we 37 00:01:14,700 --> 00:01:16,360 used for XML, it's reformatted 38 00:01:17,070 --> 00:01:18,200 of course to meet the JSON 39 00:01:18,550 --> 00:01:20,770 data model, but you can compare the two directly. 40 00:01:22,080 --> 00:01:23,350 Lastly, we do have 41 00:01:23,640 --> 00:01:25,170 the file for the data on 42 00:01:25,620 --> 00:01:26,560 the website, and I do 43 00:01:26,710 --> 00:01:27,950 suggest that you download the 44 00:01:28,020 --> 00:01:28,840 file so that you can 45 00:01:29,080 --> 00:01:30,780 take a look at it closely on your own computer. 46 00:01:31,530 --> 00:01:31,910 All right. 47 00:01:32,280 --> 00:01:33,120 So, let's see what we have, 48 00:01:33,460 --> 00:01:34,480 right now we're in 49 00:01:34,820 --> 00:01:36,240 an editor for JSON data. 50 00:01:36,660 --> 00:01:37,710 It happens to be the Eclipse 51 00:01:38,080 --> 00:01:38,820 editor and we're going to 52 00:01:38,880 --> 00:01:39,810 make make some edits to the 53 00:01:39,940 --> 00:01:41,160 file after we look through 54 00:01:41,940 --> 00:01:42,940 the constructs of the file. 55 00:01:43,740 --> 00:01:45,630 So, this is JSON 56 00:01:45,690 --> 00:01:47,920 data representing books and 57 00:01:48,120 --> 00:01:49,550 magazines, and we have 58 00:01:49,650 --> 00:01:51,380 a little more information about our books and our magazines. 59 00:01:52,390 --> 00:01:53,830 So, at the outermost, the 60 00:01:53,920 --> 00:01:56,510 curly brace indicates that this is a JSON object. 61 00:01:57,390 --> 00:01:58,670 And as a reminder, an object 62 00:01:59,140 --> 00:02:00,390 is a set of label-value 63 00:02:01,430 --> 00:02:02,720 pairs, separated by commas. 64 00:02:03,620 --> 00:02:06,610 So, our first value is the label "books". And 65 00:02:07,700 --> 00:02:09,550 then our first element in 66 00:02:09,660 --> 00:02:11,130 the object is the label books 67 00:02:11,560 --> 00:02:13,800 and this big value and the 68 00:02:14,490 --> 00:02:15,690 second, so there's only two label-value 69 00:02:16,040 --> 00:02:17,640 pairs here, is the 70 00:02:17,750 --> 00:02:20,520 label magazines and this big value here. 71 00:02:21,180 --> 00:02:22,770 And let's take a look first at magazines. 72 00:02:23,910 --> 00:02:25,080 So magazines, again, is the 73 00:02:25,180 --> 00:02:26,300 label and the value we 74 00:02:26,450 --> 00:02:27,390 can see with the square 75 00:02:27,850 --> 00:02:29,290 brackets here is an array. 76 00:02:30,220 --> 00:02:31,490 An array is a list of 77 00:02:31,620 --> 00:02:33,110 values and here we 78 00:02:33,340 --> 00:02:34,720 have two values in our array. 79 00:02:35,080 --> 00:02:36,240 They're still composite values. 80 00:02:37,020 --> 00:02:38,340 So, we have two values, each 81 00:02:38,590 --> 00:02:39,910 of which is an object, 82 00:02:40,280 --> 00:02:41,890 a set of label-value pairs. 83 00:02:42,700 --> 00:02:45,580 Let me mention, sometimes people call these labels 'properties', by the way. 84 00:02:46,740 --> 00:02:47,930 Okay. So, now we are inside 85 00:02:48,280 --> 00:02:49,570 our 2 objects that are 86 00:02:49,700 --> 00:02:52,140 the 2 elements in the array that's the value of magazines. 87 00:02:53,110 --> 00:02:54,580 And each one of those has 88 00:02:54,800 --> 00:02:56,470 3 labels and 3 values. 89 00:02:56,920 --> 00:02:58,480 And now we're finally down to the base values. 90 00:02:58,860 --> 00:02:59,950 So, we have the title being "National 91 00:03:00,400 --> 00:03:02,160 Geographic", a string, the 92 00:03:02,260 --> 00:03:03,810 month being January, a string 93 00:03:04,500 --> 00:03:05,500 and the year 2009, where 2009 is an integer. 94 00:03:06,330 --> 00:03:08,190 And again, we have 95 00:03:08,650 --> 00:03:11,760 another object here that's a different magazine 96 00:03:12,140 --> 00:03:14,680 with a different name, month and happens to be the same year. 97 00:03:15,270 --> 00:03:16,610 Now, these two have exactly the 98 00:03:16,670 --> 00:03:17,820 same structure but they don't 99 00:03:18,130 --> 00:03:19,170 have to and we will 100 00:03:19,380 --> 00:03:21,150 see that as we start editing the file. 101 00:03:21,990 --> 00:03:22,850 But before we edit the file, 102 00:03:23,190 --> 00:03:24,170 let's go and look at 103 00:03:24,590 --> 00:03:25,860 our books here. 104 00:03:26,140 --> 00:03:27,370 The value of our other 105 00:03:28,550 --> 00:03:29,880 label-value pair inside the 106 00:03:30,110 --> 00:03:31,930 outermost object, "books" is 107 00:03:32,100 --> 00:03:34,070 also an array, and 108 00:03:34,270 --> 00:03:35,450 the array in this case also 109 00:03:35,870 --> 00:03:38,720 has just two elements, so we've represented two books here. 110 00:03:38,950 --> 00:03:40,330 It's a little more complicated than the 111 00:03:40,390 --> 00:03:42,040 magazines, but those elements 112 00:03:42,560 --> 00:03:44,790 are still objects that are label-value pairs. 113 00:03:45,720 --> 00:03:46,860 So, we have now the ISBN, 114 00:03:47,440 --> 00:03:48,990 the price, the addition, the title, 115 00:03:49,700 --> 00:03:51,010 all either integers or strings, 116 00:03:51,970 --> 00:03:54,090 and then we have one nested composite 117 00:03:54,750 --> 00:03:55,620 object which is the authors 118 00:03:56,210 --> 00:03:57,600 and that's an array again. 119 00:03:57,810 --> 00:04:01,070 So, the array again, is indicated by the square brackets. 120 00:04:02,290 --> 00:04:04,120 And inside this array, we 121 00:04:04,300 --> 00:04:05,920 have two authors and each 122 00:04:06,130 --> 00:04:07,180 of the authors has a first 123 00:04:07,360 --> 00:04:08,290 name and a last name, 124 00:04:08,850 --> 00:04:10,230 but again, that uniformity is 125 00:04:10,380 --> 00:04:13,100 not required by the model itself, as we'll see. 126 00:04:13,310 --> 00:04:14,920 So, as I mentioned, 127 00:04:15,370 --> 00:04:16,620 this is actually an editor for 128 00:04:16,730 --> 00:04:19,120 JSON data and we're going to come back to this editor in a moment. 129 00:04:19,280 --> 00:04:20,080 But what I wanted to do is 130 00:04:20,300 --> 00:04:21,560 show the same data 131 00:04:22,060 --> 00:04:23,310 in a browser because browsers 132 00:04:23,690 --> 00:04:24,850 actually offer some nice features 133 00:04:25,380 --> 00:04:26,370 for navigating in JSON. 134 00:04:27,860 --> 00:04:28,570 So here we are in the 135 00:04:28,680 --> 00:04:30,020 Chrome browser, which has nice 136 00:04:30,290 --> 00:04:31,820 features for navigating JSON, 137 00:04:32,720 --> 00:04:33,640 and other browsers do as well. 138 00:04:34,570 --> 00:04:35,850 We can see here again that we 139 00:04:35,990 --> 00:04:37,440 have an object in 140 00:04:37,530 --> 00:04:39,050 our JSON data, that consists 141 00:04:39,200 --> 00:04:40,430 of two label-value pairs; 142 00:04:40,820 --> 00:04:42,680 books and magazines, which are 143 00:04:42,730 --> 00:04:43,550 currently closed and and then 144 00:04:43,620 --> 00:04:46,180 this plus allows us to open them up, and see the structure. 145 00:04:47,160 --> 00:04:48,180 For example, we open magazines 146 00:04:48,820 --> 00:04:51,440 and we see that magazines is an array containing two objects. 147 00:04:52,210 --> 00:04:53,060 We can open one of those 148 00:04:53,400 --> 00:04:55,450 objects, and see that the three label-value pairs. 149 00:04:55,940 --> 00:04:58,530 Now we're at the lowest levels and similarly for the other object. 150 00:04:59,590 --> 00:05:00,460 We can see here that Books 151 00:05:00,720 --> 00:05:03,480 is also an array, and we go ahead and open it up. 152 00:05:03,700 --> 00:05:04,750 It's an array of two objects. 153 00:05:05,110 --> 00:05:06,070 We open one of those 154 00:05:06,400 --> 00:05:07,540 objects and we see again 155 00:05:07,880 --> 00:05:09,340 the set of label-value pairs, 156 00:05:09,610 --> 00:05:10,300 where one of the values 157 00:05:10,800 --> 00:05:12,000 is a further nesting. 158 00:05:12,610 --> 00:05:14,060 It's an array and we open 159 00:05:14,440 --> 00:05:15,330 that array, and we see 160 00:05:15,450 --> 00:05:16,400 two objects, and we open 161 00:05:16,690 --> 00:05:18,820 them and finally see the data at the lowest levels. 162 00:05:19,420 --> 00:05:21,000 So again, the browser 163 00:05:21,480 --> 00:05:22,390 here gives us a nice way 164 00:05:22,650 --> 00:05:25,470 to navigate the JSON data and see its structure. 165 00:05:26,910 --> 00:05:28,330 So now we're back to our JSON editor. 166 00:05:28,990 --> 00:05:30,560 By the way, this editor, Eclipse, does 167 00:05:30,750 --> 00:05:32,340 also have some features for 168 00:05:32,580 --> 00:05:33,570 opening and closing the structure 169 00:05:34,150 --> 00:05:35,480 of the data, but it's 170 00:05:35,960 --> 00:05:37,900 not quite as nice as the browser that we use. 171 00:05:38,130 --> 00:05:39,310 So we decided to use the browser instead. 172 00:05:39,820 --> 00:05:40,810 What we are going to 173 00:05:40,900 --> 00:05:42,210 use the editor for is to 174 00:05:42,340 --> 00:05:43,400 make some changes to the 175 00:05:43,490 --> 00:05:44,510 JSON data and see which 176 00:05:44,840 --> 00:05:47,230 changes are legal and which aren't. 177 00:05:47,580 --> 00:05:50,250 So, let's take a look at the first change, a very simple one. 178 00:05:50,430 --> 00:05:51,470 What if we forgot a comma. 179 00:05:52,010 --> 00:05:53,140 Well, when we try to 180 00:05:53,320 --> 00:05:54,250 save that file, we get a 181 00:05:54,430 --> 00:05:55,360 little notice that we have an 182 00:05:55,510 --> 00:05:56,830 error, we expected an 183 00:05:56,930 --> 00:05:58,700 N value, so that's a 184 00:05:58,850 --> 00:06:01,680 pretty straightforward mistake, let's put that comma back. 185 00:06:02,660 --> 00:06:04,470 Let's say insert an 186 00:06:04,680 --> 00:06:07,190 extra brace somewhere here, for whatever reason. 187 00:06:07,560 --> 00:06:09,060 We accidentally put in an extra brace. 188 00:06:09,790 --> 00:06:11,940 Again we see that that's marked as an error. 189 00:06:13,160 --> 00:06:13,920 So an error that can 190 00:06:13,990 --> 00:06:15,230 be fairly common to make is 191 00:06:15,330 --> 00:06:17,450 to forget to put quotes around strings. 192 00:06:18,090 --> 00:06:19,520 So, for example, this ISBN 193 00:06:20,170 --> 00:06:22,840 number here, if we don't quote it, we're gonna get an error. 194 00:06:23,650 --> 00:06:24,690 As we'll see the only things that can 195 00:06:24,770 --> 00:06:26,630 be unquoted are numbers and 196 00:06:27,030 --> 00:06:28,740 the values null, true and false. 197 00:06:29,060 --> 00:06:30,830 So, let's put our quotes back there. 198 00:06:31,660 --> 00:06:32,960 Now, actually, even more 199 00:06:33,160 --> 00:06:34,310 common is to forget to 200 00:06:34,440 --> 00:06:36,940 put quotes around the labels in label-value pairs. 201 00:06:37,710 --> 00:06:40,250 But if we forget to quote that, that's going to be an error as well. 202 00:06:40,770 --> 00:06:41,710 You might have noticed, by the 203 00:06:41,790 --> 00:06:42,630 way, when we use the browser 204 00:06:43,510 --> 00:06:44,550 that the browser didn't even show 205 00:06:44,930 --> 00:06:46,290 us the quotes in the labels. 206 00:06:46,800 --> 00:06:47,690 But you do when you make 207 00:06:47,970 --> 00:06:50,680 the raw JSON data, you do need to include those quotes. 208 00:06:51,710 --> 00:06:54,330 Speaking of quotes, what if we quoted our price here. 209 00:06:56,210 --> 00:06:57,100 Well that's actually not an 210 00:06:57,190 --> 00:06:58,380 error, because now we've simply turned 211 00:06:58,670 --> 00:07:00,300 price into a string, and 212 00:07:00,570 --> 00:07:02,680 string values are perfectly well allowed anywhere. 213 00:07:03,310 --> 00:07:04,240 Now we'll see when we use 214 00:07:04,480 --> 00:07:05,480 JSON's schema that we 215 00:07:05,590 --> 00:07:06,950 can make restrictions that don't allow 216 00:07:07,180 --> 00:07:08,320 strings in certain places, but 217 00:07:08,890 --> 00:07:10,530 just for syntactic correctness of 218 00:07:10,700 --> 00:07:14,000 JSON data any of our values can be strings. 219 00:07:15,380 --> 00:07:16,510 Now, as I mentioned, there are 220 00:07:16,580 --> 00:07:17,740 a few values that are 221 00:07:17,960 --> 00:07:19,720 sort of reserved words in JSON. 222 00:07:20,450 --> 00:07:22,250 For example, true is a 223 00:07:22,390 --> 00:07:24,020 reserved word for a bullion value. 224 00:07:24,420 --> 00:07:25,580 That means we don't need to 225 00:07:25,760 --> 00:07:26,770 quote it because it's actually 226 00:07:27,190 --> 00:07:28,330 its own special type of value. 227 00:07:28,880 --> 00:07:29,650 And so is false. 228 00:07:30,390 --> 00:07:31,550 And the third one is null, 229 00:07:32,270 --> 00:07:34,180 so there's a built-in concept of null. 230 00:07:35,030 --> 00:07:36,460 Now, if we wanted to 231 00:07:36,630 --> 00:07:38,140 use nil for whatever reason 232 00:07:38,160 --> 00:07:39,360 instead of null, well, now 233 00:07:39,650 --> 00:07:40,440 we're going to get an error because 234 00:07:40,700 --> 00:07:41,760 nil is not a reserved word, 235 00:07:42,140 --> 00:07:43,260 and if we really wanted nil 236 00:07:43,530 --> 00:07:45,930 then we would need to actually make it a quoted string. 237 00:07:47,880 --> 00:07:49,690 Now, let's take a look inside our author list. 238 00:07:50,180 --> 00:07:51,030 And I'm going to show you 239 00:07:51,240 --> 00:07:52,680 that arrays do not have 240 00:07:52,900 --> 00:07:54,000 to have the same type of 241 00:07:54,070 --> 00:07:55,720 value for every element in the array. 242 00:07:56,350 --> 00:07:57,880 So here we have a homogeneous 243 00:07:58,400 --> 00:07:59,530 list of authors. Both of them 244 00:07:59,670 --> 00:08:00,970 are objects with a first 245 00:08:01,170 --> 00:08:02,060 name and a last name as 246 00:08:02,220 --> 00:08:03,750 separate label-value pairs, 247 00:08:04,260 --> 00:08:05,520 but if I change that 248 00:08:05,900 --> 00:08:07,180 first one, the entire value 249 00:08:07,980 --> 00:08:09,220 to be, instead of a 250 00:08:09,530 --> 00:08:10,780 composite one, simply the string, 251 00:08:11,330 --> 00:08:13,020 Jefferey Ullman. Oops, sorry 252 00:08:13,270 --> 00:08:15,360 about my typing there, and that 253 00:08:15,670 --> 00:08:16,920 is not an error, it 254 00:08:17,020 --> 00:08:18,280 is allowed to have a string, 255 00:08:18,830 --> 00:08:19,810 and then a composite object. 256 00:08:20,200 --> 00:08:22,380 And we could even have an array, and anything we want. 257 00:08:22,920 --> 00:08:23,970 In an array, when you 258 00:08:24,030 --> 00:08:25,220 have a list of values, all 259 00:08:25,370 --> 00:08:26,150 you need is for each one 260 00:08:26,660 --> 00:08:29,010 to be syntactically a correct value in JSON. 261 00:08:30,220 --> 00:08:31,240 Now let's go visit our magazines 262 00:08:32,000 --> 00:08:33,620 for a moment here and let 263 00:08:33,800 --> 00:08:35,550 me show that empty objects are okay. 264 00:08:35,740 --> 00:08:37,360 So a list of label 265 00:08:37,790 --> 00:08:40,780 value pairs, comprising an object, can be the empty list. 266 00:08:41,460 --> 00:08:42,630 And so now I've turned this magazine 267 00:08:42,970 --> 00:08:44,290 into having no information about 268 00:08:44,550 --> 00:08:46,090 it, but that is legal in JSON. 269 00:08:46,420 --> 00:08:50,130 And similarly, arrays are allowed to be of zero length. 270 00:08:50,910 --> 00:08:51,900 So I can take these authors 271 00:08:52,360 --> 00:08:53,090 here and I can just take 272 00:08:53,430 --> 00:08:54,680 out all of the authors, and 273 00:08:54,810 --> 00:08:57,200 make that an empty list, but that's still valid JSON. 274 00:08:58,400 --> 00:09:00,580 Now, what if I took this array out altogether? 275 00:09:01,930 --> 00:09:02,850 In that case, now we 276 00:09:02,980 --> 00:09:04,240 have an error because this is 277 00:09:04,360 --> 00:09:05,370 an object where we have 278 00:09:05,670 --> 00:09:07,270 label-value pairs and every 279 00:09:08,100 --> 00:09:09,190 label-value pair has to 280 00:09:09,290 --> 00:09:10,730 have both a label and a value. 281 00:09:12,030 --> 00:09:13,210 So let's put our array back 282 00:09:13,910 --> 00:09:14,980 and we can have anything in 283 00:09:15,100 --> 00:09:16,320 there so let's just make it 284 00:09:16,380 --> 00:09:18,480 "fu" and that corrects the error. 285 00:09:19,160 --> 00:09:20,220 What if we didn't want an 286 00:09:20,300 --> 00:09:21,380 array here instead and we 287 00:09:21,490 --> 00:09:23,740 tried to make it, say, an object,? 288 00:09:24,640 --> 00:09:25,800 Well, we're going to see an 289 00:09:26,080 --> 00:09:27,650 error there, because an object 290 00:09:28,100 --> 00:09:29,120 as a reminder and this is an 291 00:09:29,290 --> 00:09:30,440 easy mistake to make. Objects 292 00:09:30,820 --> 00:09:32,430 are always label-value pairs. 293 00:09:33,290 --> 00:09:34,370 So if you want just a value, 294 00:09:34,600 --> 00:09:36,000 that should be an array if 295 00:09:36,140 --> 00:09:37,490 you want an object, then we're 296 00:09:37,610 --> 00:09:39,000 talking about a label-value pair, so 297 00:09:39,080 --> 00:09:40,130 we can just add "fu" as 298 00:09:40,240 --> 00:09:41,780 our value, and then we're all set. 299 00:09:42,840 --> 00:09:45,580 So what we've seen so far is syntactic correctness. 300 00:09:46,400 --> 00:09:48,010 Again, there's no required 301 00:09:48,500 --> 00:09:50,290 uniformity across values in 302 00:09:50,730 --> 00:09:52,770 arrays or in the 303 00:09:52,950 --> 00:09:54,940 label-value pairs in objects we 304 00:09:55,110 --> 00:09:56,270 just need to ensure that 305 00:09:56,520 --> 00:09:57,470 all of our values, our basic 306 00:09:57,780 --> 00:09:58,590 values, are of the right types, 307 00:09:59,220 --> 00:10:00,320 and things like our commas and 308 00:10:00,450 --> 00:10:02,040 curly braces are all in place. 309 00:10:02,880 --> 00:10:04,080 What we're gonna do next is look 310 00:10:04,230 --> 00:10:05,630 at JSON's schema where we 311 00:10:05,770 --> 00:10:07,760 have a mechanism for enforcing certain 312 00:10:08,080 --> 00:10:10,200 constraints beyond simple syntactic correctness. 313 00:10:11,830 --> 00:10:13,010 If you've been very observant, you 314 00:10:13,100 --> 00:10:14,150 might even have noticed that we 315 00:10:14,260 --> 00:10:15,350 have a second tab up 316 00:10:15,470 --> 00:10:17,110 here in our editor for a 317 00:10:17,270 --> 00:10:18,620 second JSON file, and this file 318 00:10:18,960 --> 00:10:19,710 is going to be the schema 319 00:10:20,340 --> 00:10:22,290 for our bookstore data. We're using 320 00:10:22,770 --> 00:10:24,310 JSON schema, and JSON 321 00:10:25,130 --> 00:10:26,660 schema, like, XML schema 322 00:10:27,080 --> 00:10:28,660 is expressed in the data model itself. 323 00:10:29,400 --> 00:10:31,120 So, our schema description for 324 00:10:31,310 --> 00:10:32,660 this JSON data is itself 325 00:10:33,180 --> 00:10:35,220 JSON data, and here it is. 326 00:10:35,370 --> 00:10:36,420 And it's going to take a bit of time to explain. 327 00:10:37,110 --> 00:10:37,750 Now the first thing that you might 328 00:10:37,980 --> 00:10:38,970 notice is wow, the schema 329 00:10:39,420 --> 00:10:41,340 looks more complicated and in 330 00:10:41,500 --> 00:10:42,920 fact longer than the data itself. 331 00:10:43,490 --> 00:10:46,390 Well, that is true, but that's mostly because our data file is tiny. 332 00:10:47,080 --> 00:10:48,980 So, if we had thousands, you know, tens 333 00:10:49,230 --> 00:10:50,390 of thousands of books and magazines, 334 00:10:51,460 --> 00:10:52,830 our schema file wouldn't 335 00:10:53,140 --> 00:10:54,170 change, but our data file would 336 00:10:54,310 --> 00:10:56,310 be much longer and that's the typical case, in reality. 337 00:10:57,580 --> 00:10:58,650 Now, this video is not a 338 00:10:58,790 --> 00:11:00,610 complete tutorial about JSON's schema. 339 00:11:01,030 --> 00:11:02,350 There's many constructs in JSON's 340 00:11:02,750 --> 00:11:04,200 schema that weren't needed to 341 00:11:04,560 --> 00:11:05,860 describe the bookstore data, for example. 342 00:11:06,760 --> 00:11:08,230 And even this file here, 343 00:11:08,530 --> 00:11:10,860 I'm not gonna go through every detail of it right here. 344 00:11:11,570 --> 00:11:12,610 You can download the file and 345 00:11:12,720 --> 00:11:14,620 take a look, read a little more about JSON schema. 346 00:11:15,230 --> 00:11:15,980 I'm just going to give the 347 00:11:16,320 --> 00:11:17,360 flavor of the schema 348 00:11:17,740 --> 00:11:19,150 specification and then we're 349 00:11:19,290 --> 00:11:20,520 going to work with validating the data 350 00:11:20,870 --> 00:11:23,200 itself to see how the schema and data work together. 351 00:11:24,050 --> 00:11:27,040 But to give you the flavor here, let's go through at least some portions of the schema. 352 00:11:28,200 --> 00:11:29,400 So, in some sense, 353 00:11:29,560 --> 00:11:31,160 the structure of the schema file 354 00:11:31,620 --> 00:11:33,830 reflects the structure of the data file that it's describing. 355 00:11:34,550 --> 00:11:37,020 So, the outermost constructs in 356 00:11:37,180 --> 00:11:38,140 the schema file are the 357 00:11:38,330 --> 00:11:39,450 outermost in the data file and 358 00:11:39,560 --> 00:11:41,550 as we nest it parallels the nesting. 359 00:11:42,460 --> 00:11:43,430 Let me just show a little 360 00:11:43,680 --> 00:11:46,390 bit here, we'll probably look at most of it in the context of validation. 361 00:11:48,470 --> 00:11:51,880 So, we see here that our outermost construct in our data file is an object. 362 00:11:52,680 --> 00:11:53,610 And that's told to us, 363 00:11:53,780 --> 00:11:54,970 because we have "type" as 364 00:11:55,080 --> 00:11:56,820 one of our built-in labels for the schema. 365 00:11:57,270 --> 00:11:58,250 So we we have an 366 00:11:58,540 --> 00:12:00,500 object with two properties, as 367 00:12:00,610 --> 00:12:01,710 we can see here, the book's property 368 00:12:02,630 --> 00:12:03,500 and the magazine's property. 369 00:12:04,650 --> 00:12:05,540 And I use the word 370 00:12:05,770 --> 00:12:07,630 "labels" frequently for label-value 371 00:12:07,880 --> 00:12:10,540 pairs, that's synonymous with property value pairs. 372 00:12:11,640 --> 00:12:13,040 Then inside the books property 373 00:12:13,550 --> 00:12:14,860 for example, we see that 374 00:12:15,010 --> 00:12:16,130 the type of that is array, 375 00:12:16,550 --> 00:12:18,570 so we've got a label-value pair where the value is an array. 376 00:12:19,250 --> 00:12:22,010 And then we follow the nesting and see that it's an array of objects. 377 00:12:22,420 --> 00:12:23,890 And we go further down and we 378 00:12:24,160 --> 00:12:25,630 see the different label-value pairs 379 00:12:26,010 --> 00:12:27,390 of the object that make up 380 00:12:27,510 --> 00:12:30,240 the books and nesting further into the authors and so on. 381 00:12:31,000 --> 00:12:32,230 We see similarly for magazines 382 00:12:32,960 --> 00:12:34,120 that the value of the 383 00:12:34,770 --> 00:12:36,110 a label-value pair for 384 00:12:36,230 --> 00:12:37,530 magazines is an array, and 385 00:12:37,940 --> 00:12:40,080 that array consists of objects with further nesting. 386 00:12:41,030 --> 00:12:42,070 So what we're looking at here is 387 00:12:42,150 --> 00:12:45,180 an online JSON schema validator. We have two windows. 388 00:12:45,550 --> 00:12:46,450 On the left we have our 389 00:12:46,540 --> 00:12:47,570 schema and on the 390 00:12:47,650 --> 00:12:48,910 right we have our data, and 391 00:12:49,070 --> 00:12:50,320 this is exactly the same data 392 00:12:50,590 --> 00:12:53,130 file and schema file that we were looking at earlier. 393 00:12:54,010 --> 00:12:55,200 If we hit the validate button, 394 00:12:55,710 --> 00:12:57,610 hopefully everything should work and it does. 395 00:12:58,150 --> 00:12:59,230 This tells us that the 396 00:12:59,290 --> 00:13:01,910 JSON data is valid with respect to the schema. 397 00:13:03,100 --> 00:13:04,420 Now, this system will of 398 00:13:04,590 --> 00:13:06,200 course find basic syntactic errors 399 00:13:06,470 --> 00:13:07,540 so I can take away a comma 400 00:13:07,760 --> 00:13:08,830 just like I did before and 401 00:13:09,030 --> 00:13:10,110 when I validate I'll get a 402 00:13:10,380 --> 00:13:12,570 parsing error that really has nothing to do with the schema. 403 00:13:13,280 --> 00:13:14,040 What I'm going to focus on 404 00:13:14,200 --> 00:13:16,150 now is actually validating 405 00:13:16,490 --> 00:13:17,770 semantic correctness of the Jason 406 00:13:18,440 --> 00:13:19,260 with respect back to the constructs 407 00:13:19,750 --> 00:13:20,830 that we've specified in this schema. 408 00:13:21,390 --> 00:13:24,250 Let me first put that comma back so we start with a valid file. 409 00:13:25,330 --> 00:13:26,440 So, the first thing I'll show is 410 00:13:26,770 --> 00:13:28,110 the ability to constrain basic 411 00:13:28,410 --> 00:13:29,270 types, and then the ability 412 00:13:29,670 --> 00:13:31,850 to constrain the range of values of those basic types. 413 00:13:32,180 --> 00:13:33,730 And let's focus on price. 414 00:13:34,470 --> 00:13:35,450 So here we're talking about the 415 00:13:35,560 --> 00:13:37,640 price property inside books and 416 00:13:37,760 --> 00:13:38,890 we specify in our schema 417 00:13:39,580 --> 00:13:41,760 that the type of the price must be an integer. 418 00:13:42,500 --> 00:13:43,790 So, for example, if our 419 00:13:44,010 --> 00:13:45,490 price were instead a string 420 00:13:46,220 --> 00:13:47,040 and we went ahead and try 421 00:13:47,260 --> 00:13:49,010 to validate that we would get an error. 422 00:13:49,950 --> 00:13:51,080 Let's make it back into an 423 00:13:51,300 --> 00:13:52,880 integer but let's make 424 00:13:53,680 --> 00:13:56,210 it into the integer 300 now instead of 100. 425 00:13:56,600 --> 00:13:58,340 And why am I doing that? 426 00:13:58,610 --> 00:13:59,970 Because the JSON schema also 427 00:14:00,410 --> 00:14:01,860 lets me constrain the range of 428 00:14:01,970 --> 00:14:04,270 values that are allowed if we have a numeric value. 429 00:14:05,140 --> 00:14:06,280 So, not only in price did I 430 00:14:06,660 --> 00:14:08,140 say that it's an integer but 431 00:14:08,260 --> 00:14:09,310 I also said that it 432 00:14:09,460 --> 00:14:11,090 has a minimum and maximum value, 433 00:14:11,600 --> 00:14:12,980 the integer of prices must 434 00:14:13,250 --> 00:14:14,840 be between 0 and 200. 435 00:14:15,430 --> 00:14:16,280 So, if I try to make 436 00:14:16,370 --> 00:14:18,100 the price of 300, and I 437 00:14:18,240 --> 00:14:20,090 validate, I'm again getting an error. 438 00:14:20,400 --> 00:14:21,400 Now it's not a type error, 439 00:14:21,910 --> 00:14:22,890 but it's an error that my 440 00:14:23,020 --> 00:14:24,810 integer was outside of the allowed range. 441 00:14:26,340 --> 00:14:27,360 I've put the price back to 442 00:14:27,480 --> 00:14:28,560 a hundred, and now let's 443 00:14:28,810 --> 00:14:30,840 look at constraints on string values. 444 00:14:32,160 --> 00:14:33,290 JSON schema actually has 445 00:14:33,540 --> 00:14:35,050 a little pattern matching language that 446 00:14:35,160 --> 00:14:36,540 can be used to constrain the 447 00:14:36,630 --> 00:14:39,290 allowable strings for a specific type of value. 448 00:14:40,230 --> 00:14:42,750 We'll look at ISBN number here as an example of that. 449 00:14:43,380 --> 00:14:44,950 We've said that ISBN is 450 00:14:45,240 --> 00:14:46,930 of type string, and then 451 00:14:47,080 --> 00:14:48,390 we've further constrained in the 452 00:14:48,560 --> 00:14:49,940 schema that the string values for 453 00:14:50,050 --> 00:14:51,980 ISBN must satisfy a certain pattern. 454 00:14:52,720 --> 00:14:55,380 I'm not gonna go into the details of this pattern-matching language. 455 00:14:56,210 --> 00:14:57,120 I'm just gonna give an example. 456 00:14:57,680 --> 00:14:59,000 And in fact, this entire demo is 457 00:14:59,140 --> 00:15:00,520 really just an example lots of 458 00:15:00,620 --> 00:15:02,680 things in JSON's schema that we're not seeing. 459 00:15:03,430 --> 00:15:05,120 What this pattern here says is 460 00:15:05,350 --> 00:15:06,890 that the string value for 461 00:15:06,980 --> 00:15:08,790 ISBN must start with 462 00:15:08,920 --> 00:15:12,170 the four characters ISBN and then can be followed by anything else. 463 00:15:13,080 --> 00:15:13,940 So, if we go over to our 464 00:15:14,110 --> 00:15:15,190 data and we look at 465 00:15:15,360 --> 00:15:16,880 the ISBN number here and 466 00:15:17,060 --> 00:15:18,110 say we have a typo, we 467 00:15:18,300 --> 00:15:20,000 forgot the "I" and we try to validate. 468 00:15:20,790 --> 00:15:22,100 Then we'll see that our data 469 00:15:22,420 --> 00:15:23,880 no longer matches our schema specification. 470 00:15:25,740 --> 00:15:28,480 Now let's look at some other constraints we can specify in JSON's schema. 471 00:15:29,450 --> 00:15:31,800 We can constrain the number of elements in an array. 472 00:15:32,150 --> 00:15:34,440 We can give a minimum or maximum or both. 473 00:15:35,400 --> 00:15:37,750 And I've done that here in the context of the authors array. 474 00:15:38,120 --> 00:15:39,650 Remember the authors are 475 00:15:39,690 --> 00:15:40,660 an array that's a list of 476 00:15:40,730 --> 00:15:42,690 objects and here I've said that 477 00:15:42,890 --> 00:15:44,010 we have a minimum number of 478 00:15:44,080 --> 00:15:45,040 items of 1 and a 479 00:15:45,430 --> 00:15:46,570 maximum number items of 10. 480 00:15:46,750 --> 00:15:48,160 In other words, every book 481 00:15:48,440 --> 00:15:50,490 has to have between one and ten authors. 482 00:15:51,420 --> 00:15:52,640 So let's try, for example, 483 00:15:53,190 --> 00:15:55,620 taking out all of our authors here in our first book. 484 00:15:56,180 --> 00:15:57,100 We actually looked at this before in terms 485 00:15:57,850 --> 00:15:59,220 of syntactic validity, and it 486 00:15:59,270 --> 00:16:00,950 was perfectly valid to have an empty array. 487 00:16:01,450 --> 00:16:02,380 But when we try to validate 488 00:16:02,860 --> 00:16:03,760 now we do get an 489 00:16:03,880 --> 00:16:04,990 error, and the reason is 490 00:16:05,140 --> 00:16:05,980 that we said that we needed 491 00:16:06,240 --> 00:16:09,210 between one and ten array elements in the case of authors. 492 00:16:10,460 --> 00:16:11,930 Now let's fix that, 493 00:16:12,020 --> 00:16:13,170 not by putting our authors back 494 00:16:13,540 --> 00:16:14,520 but let's say we actually decide 495 00:16:14,910 --> 00:16:17,160 we would like to be able to have books that have no authors. 496 00:16:17,630 --> 00:16:18,880 So, we can simply fix 497 00:16:19,070 --> 00:16:20,770 that by changing that minimum 498 00:16:21,400 --> 00:16:23,190 item to zero and that 499 00:16:23,400 --> 00:16:24,910 makes our data valid again and 500 00:16:24,950 --> 00:16:26,100 in fact, we could actually take that 501 00:16:26,270 --> 00:16:27,550 minimum constraint out all together, 502 00:16:28,470 --> 00:16:30,670 and if we do that our data is still going to be valid. 503 00:16:32,820 --> 00:16:33,570 Now let's see what happens when we 504 00:16:33,700 --> 00:16:36,240 add something to our data that isn't mentioned in the schema. 505 00:16:36,920 --> 00:16:38,050 If you look carefully you'll see 506 00:16:38,270 --> 00:16:39,120 that everything that we have 507 00:16:39,440 --> 00:16:41,940 in the data so far has been specified in the schema. 508 00:16:42,210 --> 00:16:43,420 Let's say we come along 509 00:16:43,830 --> 00:16:46,000 and decide were gonna also have ratings for our books. 510 00:16:46,330 --> 00:16:47,510 So let's add here a 511 00:16:47,930 --> 00:16:50,790 rating label property with the value 5. 512 00:16:51,850 --> 00:16:53,320 We go ahead and validate, you 513 00:16:53,610 --> 00:16:54,490 probaly think it's not going to 514 00:16:54,660 --> 00:16:56,870 validate properly but actually it did. 515 00:16:57,360 --> 00:16:58,830 The definition of JSON 516 00:16:59,270 --> 00:17:00,760 schema that it can constrain things by 517 00:17:00,920 --> 00:17:02,220 describing them but you 518 00:17:02,340 --> 00:17:03,860 can also have components in 519 00:17:04,080 --> 00:17:05,950 the data that aren't present in this schema. 520 00:17:06,700 --> 00:17:07,680 If we want to insist 521 00:17:08,270 --> 00:17:10,330 that every property that is 522 00:17:10,520 --> 00:17:11,510 present in the data is 523 00:17:11,670 --> 00:17:12,620 also described in this 524 00:17:12,900 --> 00:17:13,880 schema, then we can 525 00:17:14,030 --> 00:17:16,500 actually add a constraint to the schema that tells us that. 526 00:17:17,120 --> 00:17:20,290 Specifically, under the object 527 00:17:20,740 --> 00:17:21,940 here, we can put in 528 00:17:22,390 --> 00:17:23,620 a special flag which itself 529 00:17:24,090 --> 00:17:26,740 is specified as a label called additional properties. 530 00:17:27,800 --> 00:17:29,030 And this flag if we 531 00:17:29,250 --> 00:17:31,000 set it to false and remember 532 00:17:31,430 --> 00:17:32,520 false can is actually a keyword 533 00:17:32,960 --> 00:17:34,310 in json's schema, tells us 534 00:17:34,520 --> 00:17:35,800 that in our data we're not 535 00:17:36,160 --> 00:17:37,240 allowed to have any properties 536 00:17:37,770 --> 00:17:39,380 beyond those that are specified in the schema. 537 00:17:40,490 --> 00:17:41,860 So now we validate and we 538 00:17:41,930 --> 00:17:43,200 get an error, because the property 539 00:17:43,640 --> 00:17:45,100 rating hasn't been defined in the schema. 540 00:17:46,180 --> 00:17:47,530 If additional properties is missing, 541 00:17:48,460 --> 00:17:49,820 or have the default value 542 00:17:50,190 --> 00:17:52,550 of "true", then the validation goes through. 543 00:17:53,830 --> 00:17:56,200 Now lets take a look at our authors that are still here. 544 00:17:56,960 --> 00:17:58,130 Let's suppose that we don't 545 00:17:58,500 --> 00:18:00,800 have a first name for our middle author here. 546 00:18:01,530 --> 00:18:02,630 If we take that away and 547 00:18:02,880 --> 00:18:04,390 we try to validate, we do 548 00:18:04,620 --> 00:18:05,810 get an error, because we specified 549 00:18:06,650 --> 00:18:08,190 in our schema and it's right 550 00:18:08,440 --> 00:18:11,430 down here--that author-objects must 551 00:18:11,810 --> 00:18:13,740 have both a first name and a last name. 552 00:18:14,750 --> 00:18:15,900 It turns out that we can 553 00:18:16,290 --> 00:18:19,540 specify for every property that the property is optional. 554 00:18:20,210 --> 00:18:21,650 So, we can add to the 555 00:18:21,830 --> 00:18:23,110 description of the first 556 00:18:23,410 --> 00:18:24,390 name, not only that the 557 00:18:24,590 --> 00:18:26,020 type is a string but that that 558 00:18:26,440 --> 00:18:27,680 property is optional so we 559 00:18:27,840 --> 00:18:29,710 say optional, true. 560 00:18:31,210 --> 00:18:33,110 Now let's validate, and now we're in good shape. 561 00:18:34,380 --> 00:18:35,150 Now, let's take a look 562 00:18:35,180 --> 00:18:36,110 at what happens when we have 563 00:18:36,700 --> 00:18:37,800 object that has more than 564 00:18:37,930 --> 00:18:40,690 one instance of the same label or same property. 565 00:18:41,220 --> 00:18:43,040 So let's suppose, for example, in 566 00:18:43,160 --> 00:18:44,630 our magazine, the magazine 567 00:18:45,190 --> 00:18:46,410 has two different years, 2009 and 2011. 568 00:18:46,560 --> 00:18:52,010 This is syntactically valid, JSON, 569 00:18:52,370 --> 00:18:55,340 it meets the structure of having a list of label-value pairs. 570 00:18:55,770 --> 00:18:56,840 When we validate it, we 571 00:18:57,160 --> 00:18:59,540 see that we can't add a second property, year. 572 00:19:00,190 --> 00:19:02,200 So this validator doesn't permit 573 00:19:02,730 --> 00:19:03,810 two copies of the same 574 00:19:04,130 --> 00:19:05,510 property, and it's actually kind 575 00:19:05,890 --> 00:19:06,950 of a parsing thing and not 576 00:19:07,180 --> 00:19:08,540 so much related to JSON's schema. 577 00:19:09,300 --> 00:19:11,650 Many parsers actually do enforce 578 00:19:12,540 --> 00:19:13,800 that labels or properties need 579 00:19:14,150 --> 00:19:15,450 to be unique within objects, even 580 00:19:15,720 --> 00:19:17,650 though technically syntactically correct 581 00:19:18,300 --> 00:19:19,730 JSON does allow multiple copies. 582 00:19:20,200 --> 00:19:21,240 So that's just something to remember, 583 00:19:22,340 --> 00:19:23,760 the typical use of objects is 584 00:19:23,920 --> 00:19:25,960 to have unique labels, sometimes 585 00:19:26,170 --> 00:19:29,560 are even called keys of which evokes a concept of them unique. 586 00:19:30,040 --> 00:19:31,320 So typically they are unique. 587 00:19:32,200 --> 00:19:33,460 They don't have to be for syntactic validity. 588 00:19:34,210 --> 00:19:35,180 Usually when you wanna have 589 00:19:35,470 --> 00:19:38,050 repeated values, it actually makes more sense to create an array. 590 00:19:39,440 --> 00:19:41,690 I've taken away the second year in order to make the JSON valid again. 591 00:19:41,840 --> 00:19:43,790 Now let's take a look at months. 592 00:19:44,670 --> 00:19:46,180 I've used months to illustrate 593 00:19:46,650 --> 00:19:48,610 the enumeration constraint so we 594 00:19:48,870 --> 00:19:50,000 saw that we could constrain the 595 00:19:50,060 --> 00:19:51,840 values of integers, and we 596 00:19:52,180 --> 00:19:53,640 saw that we can constrain strings 597 00:19:54,060 --> 00:19:55,330 using a pattern, but we can 598 00:19:55,540 --> 00:19:56,880 also constrain any type by 599 00:19:57,040 --> 00:19:58,600 enumerating the values that are allowed. 600 00:19:59,340 --> 00:20:00,670 So, for the month, we've set 601 00:20:00,850 --> 00:20:02,100 it a string type which it 602 00:20:02,190 --> 00:20:03,700 is but we've further constrained it 603 00:20:03,830 --> 00:20:05,350 by saying that string must be 604 00:20:05,930 --> 00:20:07,270 either January or February. 605 00:20:08,200 --> 00:20:09,090 So, if we try to say 606 00:20:09,400 --> 00:20:14,350 put in the string March, we 607 00:20:14,530 --> 00:20:16,690 validate and we get the obvious error here. 608 00:20:17,340 --> 00:20:18,590 We can fix that by changing the 609 00:20:18,650 --> 00:20:19,810 month back, but maybe it 610 00:20:19,890 --> 00:20:20,880 makes more sense that March 611 00:20:21,260 --> 00:20:22,660 would be part of our enumeration type, 612 00:20:23,100 --> 00:20:24,200 so we'll add March to 613 00:20:24,310 --> 00:20:26,590 the possible values for months, and now we're good. 614 00:20:27,630 --> 00:20:28,770 As a next example, let's take 615 00:20:28,860 --> 00:20:29,870 a look at something that we 616 00:20:30,080 --> 00:20:31,720 saw was syntactically correct but 617 00:20:31,940 --> 00:20:32,930 isn't going to be semantically 618 00:20:33,620 --> 00:20:34,660 correct, which is when 619 00:20:34,860 --> 00:20:36,210 we have the author list 620 00:20:36,560 --> 00:20:39,450 be a mixture of objects and strings. 621 00:20:39,930 --> 00:20:42,930 So, let's put Jeffrey Ullman here just as a string. 622 00:20:43,510 --> 00:20:44,600 We saw that that was still 623 00:20:44,730 --> 00:20:46,040 valid JSON, but when we 624 00:20:46,140 --> 00:20:47,530 try to validate now, we're gonna 625 00:20:47,690 --> 00:20:49,220 get an error because we expected 626 00:20:49,770 --> 00:20:50,720 to see an object, we have 627 00:20:50,880 --> 00:20:51,900 specified that the authors 628 00:20:52,290 --> 00:20:54,340 are objects, and instead we got a string. 629 00:20:54,970 --> 00:20:56,570 Now JSON schema does allow 630 00:20:56,950 --> 00:20:58,550 us to specify that we 631 00:20:58,680 --> 00:21:00,680 can have different types of data 632 00:21:00,990 --> 00:21:02,370 in the same context, and I'm 633 00:21:02,590 --> 00:21:04,840 going to show that with a little bit of a simpler example here. 634 00:21:05,220 --> 00:21:06,310 So, let's first take away our 635 00:21:06,620 --> 00:21:08,890 author there so that we're back with a valid file. 636 00:21:09,930 --> 00:21:12,330 And what I am going to look at is simply the year values. 637 00:21:13,270 --> 00:21:14,740 So, let suppose for whatever 638 00:21:15,290 --> 00:21:16,390 reason that in our 639 00:21:16,540 --> 00:21:17,770 magazines, one of the 640 00:21:17,830 --> 00:21:20,410 years was a string and the other year was an integer. 641 00:21:21,190 --> 00:21:22,190 So that's not gonna work out 642 00:21:22,360 --> 00:21:23,460 right now because we have 643 00:21:23,640 --> 00:21:25,480 specified clearly that the year must be an integer. 644 00:21:27,120 --> 00:21:29,230 In JSON schema specifications, when we 645 00:21:29,340 --> 00:21:30,920 want to allow multiple types 646 00:21:31,370 --> 00:21:32,720 for values that are 647 00:21:32,810 --> 00:21:34,450 used in the same context, we 648 00:21:34,640 --> 00:21:35,990 actually make the type be an array. 649 00:21:36,550 --> 00:21:37,510 So instead of just saying 650 00:21:37,750 --> 00:21:38,780 integer, if we put 651 00:21:38,980 --> 00:21:40,260 an array here that has 652 00:21:40,540 --> 00:21:42,600 both integer and string that's 653 00:21:42,870 --> 00:21:43,660 telling us that our year 654 00:21:43,980 --> 00:21:44,910 value can be either an 655 00:21:45,110 --> 00:21:46,050 integer or a string 656 00:21:46,110 --> 00:21:47,140 and now when we validate, 657 00:21:48,050 --> 00:21:49,450 we get a correct JSON file. 658 00:21:50,230 --> 00:21:52,580 That concludes our demo of JSON schema validation. 659 00:21:53,720 --> 00:21:54,690 Again, we've just seen 660 00:21:54,870 --> 00:21:56,440 one example with a number 661 00:21:56,730 --> 00:21:57,810 of the constructs that are available 662 00:21:58,250 --> 00:21:59,360 in JSON schema, but it's not 663 00:21:59,740 --> 00:22:01,080 nearly exhaustive, there are many 664 00:22:01,250 --> 00:22:02,740 others, and I encourage you 665 00:22:02,970 --> 00:22:04,260 to read a bit more about it. 666 00:22:04,810 --> 00:22:06,260 You can download this data and 667 00:22:06,360 --> 00:22:07,280 this schema as a starting 668 00:22:07,830 --> 00:22:09,220 point, and start adding things playing around 669 00:22:09,560 --> 00:22:10,380 and I think you'll get a 670 00:22:10,440 --> 00:22:11,650 good feel for how JSON 671 00:22:12,180 --> 00:22:13,270 schema can be used to 672 00:22:13,370 --> 00:22:15,890 constrain the allowable data in a JSON file.