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.