Chapter 1: Introduction

Why xmlDraft? Why should a company spend it's time designing and creating yet another XML schema editor when there exists already a good number of editors on the market today. The idea for xmlDraft germinated when I was attempting to learn the W3C XML Schema language for the first time. The then new XML Schema language was great, much better than it's predecessor DTDs. It allowed for nodes to be nested, defined from other nodes (inherited, to borrow a page from OOP), and even reference external schema documents. And to top it off, it was written in XML making it a lot easier to understand. At least, so I thought at first.

When you looking at a basic XML Schema, it's pretty easy to understand, fairly straight-forward. With a simple glance, I could tell what an XML instance document of this schema should look. However, once I saw a schema that actually used the power of XML Schemas, one that was a bit more complex then the most simplistic of schemas, I realized that they were far from easy to understand. When nodes reference other "global" nodes, it started to get a little confusing. As complexTypes grew, so did the complexity of understanding how a Schema actually worked. And if there was an external reference to another document, good luck. After a while, I was no longer able to really see at a glance what a schema was trying to do.

So I turned to some of the many XML editors on the market, with careful attention to those that had support for XML Schemas. I looked at Tibco's products, Altova's XMLSpy, and even Microsoft's Studio .NET. They all have nice XML editors with XML Schema editing built in. One can manually type the schema in, or one can view a visual tree-like representation of the schema. But all of these editors missed their mark. Looking at a visual tree of the schema just doesn't help. Viewing a complexType node in text or in a visual tree is still, well, complex. Abstracting the schema text by one generation into a tree doesn't help. What is really needed is another layer of abstraction. Show me the document that this schema is defining. It's much easier to view and manipulate an Instance document than the schema.

And thus, xmlDraft was born. I figured if I was going to create great schemas, as well as maintain other schemas that might be even slightly complex, I would need a tool that showed me not only the XML Schema text, but also a visual representation of the XML Instance Document I was trying to define. This would greatly simplify my task as an XML developer.

Being a developer myself, I have certain reservations about so-called "visual" editors. So, I also have high expectations of what I want from an XSD editor. One, I want the tool to let me get as down-and-dirty with the XML Schema as I want to, something that would not prohibit me from directly editing the text. I also want something that would not only display a mock-up of the XML instance document, but allow me to tinker with this visual display and have it dynamically update my XSD text. I want something that would be extremely configurable, allowing not only my tastes to be satisfied, but also everyone else's who have differing opinions than I. And lastly, I want something that performs fast. I didn't buy a top of the line machine to have my GUI applications crawl. Since this was to be a GUI intensive application, that immediately nixed the idea of using Java and .NET. Both those languages are still too slow and clunky, so I opted for a native Windows32 application.

So off I ran to create the worlds first Instance XSD editor, xmlDraft.