C.4 Working with XML Schema

While XML Schema is at the heart of many XML-based projects, it has a few usability issues. You've no doubt noticed that it's verbose, a common problem for anything using XML. Its structures, even using the relatively simple subset of features shown here, can rapidly become complicated, and hunting through these structures to figure out in which choice or sequence a particular component is used is really not much fun. When you've created a schema yourself, it's generally tolerable, but interpreting large schemas created by other people is a challenge, especially when you're reading the structure through XML tags.

Most people who work with XML Schema seem to do so from behind the relative safety of tools, notably the commercial XML Spy (http://www.xmlspy.com/). There are many schema editors, some free, some not, all with their own pluses and minuses. Graphic diagrams can be a relief after pointy brackets. Some developers still like to work in text, but not directly in XML Schema, and they may be able to use the tools described in Appendix D for much of their schema creation work.

For some cases, it may be enough to infer schemas from existing documents. Excel 2003 has this capability built into, but getting to those schemas is a bit difficult, as described in Chapter 7. Both the Trang program described in Appendix D and Microsoft's XSDInference toolkit, at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxmlnet/html/xsdinference.asp, can give you an instant schema if you need to work with the schema separately.

The enormous feature set provided by the XML Schema recommendations gives developers a huge project to work on, and interoperability between schema tools remains tricky. The applications within Microsoft Office generally work directly with their own preferred subsets of XML Schema, and those subsets seem generally reliable, but you should definitely expect to test your schemas in Office and make sure they behave as you (and your users) expect.