Schemas can become extremely complex, and your IT department will probably create them for you, after talking to you about what types of data you need and how the XML system should work. Knowing what schemas look like will help you talk to IT about them. The illustration shows a schema setting rules for the
tag set discussed in the previous lesson.
This schema contains a set of declarations. The declarations control the type of data that each tag can contain. In this case, the sequence declaration also controls the order of the tags that reside inside the <CAT> root element. Any data file that uses this schema must have its tags in the order shown. Elsewhere in the illustration, the data type declarations control the type of data that each tag in a data file can contain: a string of letters, a number, or a Yes/No choice. As you'd expect, tags in a data file cannot contain a different type of data than what the schema declares. This is how a schema can help to validate your XML data.
(You may recall that an earlier section, “Anatomy of an XML data file,” also mentioned declarations. One of those declarations stated which schema would govern the data file's content. So the two groups of declarations are related, logically and functionally.)
So how does all this affect you? If you are a veterinarian, and you need to have your files contain additional information about your animal clients, such as their color or markings, you would have the person in charge of your XML add tags for that data. Adding those tags will also require changes to the schema for the file. If you do not change the schema, the new tags will be considered illegal, and the system will stop working. Simple schema changes may be very quick, but any schema change is important because it creates a new rule for your data.
Because you can change your schemas as your computing and data needs evolve, XML files can be adapted to new situations and requirements without rebuilding the files from scratch. Like the tags, the schema is extensible.