Without one your just building up problems for the future, and as we all know problems that are fixed early cost less in time, money and hair. So what does it actually give you. A formal definition of your data - not a woolly document, which can be interpreted, this is a rock solid description. If you've ever sent a specification off to a 3rd party, then tried to reconcile their interpretation with what you were expecting, then you'll understand.
You'll get additional data creeping in because they wanted to add stuff, things are missing because they didn't understand bits.
If you have a schema then theirs none of that. If its not valid against the schema then were not interested in it, you can then put the onus back on them to make it right Validation - You can take an XML document, and check that it complies with your schema. In fact validators are now so fast that many companies will not allow data into there process flows unless its valid against the schema. This entry point validation ensures that all data moving through the system is valid, and massively lowers the overheads caused by invalid messages.
Centralises Documentation — Your documentation for the schema can be placed within the schema itself. There are a number of tools for editing these annotations, including XML Studio. Machine readable — Because your schema is machine readable, it can be used by a number of different tools. You can produce pretty documentation from it, complete with diagrams and the documentation you painstakingly added.
You can generate code from it. Code that will read and write your XML documents making it even easier to work with. XML Editors can use the schema to provide intellisense when your editing your XML even making use of the embedded documentation. So you can either, create some XML, put a woolly document together that describes it, manually adding some hand drawn diagrams to show its structure.
Then re-code all the validation rules you described in your document, before you even start to use the XML. Putting the cart before the horse Its good practice to think about your data before you design your schema, but things normally happen the other way around, we have some data, and we want to retro fit a schema to it.
So lets look at some data. The distressed image featured on the front of this t-shirt is of the Transformers Autobot. One Microsoft Visual Studio Step 2: Create a new Schema. Add an element to the schema. A Sequence is a container for other child elements, there are 2 other containers choice and all. Give the element the name 'Product'. Change the Cardinality We want to allow lots of product elements to be present in the SalesCatalogue.
To do this we can change the cardinality. Add a sequence to 'Product' Repeat step 4 for the 'Product' node Step 8: Add a name element to products sequence Add a new element to the sequence attached to product, name it "Name" see step 3.
The previous elements we have created have been containers for other child elements i. We are now defining an element that can only contain data, in this case text.
Add more data elements Add the following elements in the same way as step 8.