XSD / XML Schema Generator

XML Schema (XSD) explained

What is an XSD?

An XML Schema Definition (XSD) describes the structure that an XML document must follow: which elements and attributes may appear, in which order, how many times, and which data type their content must have. A validating parser can then reject any document that does not conform. The schema language is itself XML and is defined by the W3C (XML Schema 1.1); a schema file conventionally uses the .xsd extension and the http://www.w3.org/2001/XMLSchema namespace, usually bound to the xs prefix.

How this generator works

• Every element of your document is visited. Elements with the same name and the same parent path are merged: the resulting declaration is the union of everything that was observed (attributes, child elements, data types).
• A child element becomes minOccurs="0" when at least one parent does not contain it and maxOccurs="unbounded" when one parent contains it more than once.
• An attribute is use="required" when every occurrence of the element carries it, use="optional" otherwise.
• Elements containing only text get a simple type; elements with attributes and text use xs:simpleContent; elements with child elements get an xs:sequence. Elements that contain both text and child elements are declared mixed="true".
• The root element's namespace becomes the targetNamespace (with elementFormDefault="qualified"). Elements and attributes from other namespaces are not described: they are replaced by xs:any / xs:anyAttribute wildcards with a comment, because one XSD file can only define a single namespace.

Data type inference

When the option is enabled, every text value and attribute value observed for a given element is examined and the most specific built-in type that accepts all of them is chosen:

When the values disagree the type is widened: xs:integer + xs:decimal gives xs:decimal, any numeric type + xs:double gives xs:double, and any other combination falls back to xs:string. Empty values are ignored during inference. Note that a ZIP code such as 90952 is inferred as an integer: review the generated types and change them when they are too permissive or too strict for your data.

Russian Doll, Salami Slice and Venetian Blind

The three classic schema design patterns (popularized by Roger L. Costello's xfront.com guidelines) describe the same content model but organize the declarations differently. Given this document:

<book id="1">
   <title>XML Schema</title>
   <price>29.99</price>
</book>

Russian Doll

One global element (the root); every other element is declared inline, nested inside the anonymous type of its parent, exactly like the document itself. The schema mirrors the instance structure and each element is only valid in its context.

<xs:element name="book">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="title" type="xs:string"/>
      <xs:element name="price" type="xs:decimal"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:integer" use="required"/>
  </xs:complexType>
</xs:element>

• Pros: compact, self-contained, easy to read for small documents; element names cannot clash because nothing is global except the root.
• Cons: no reuse at all (an address used twice is declared twice), deeply nested and hard to maintain for large documents.

Salami Slice

Every element is declared once at the top level of the schema and parents reference their children with ref="…". The document is "sliced" into independent global declarations.

<xs:element name="title" type="xs:string"/>
<xs:element name="price" type="xs:decimal"/>
<xs:element name="book">
  <xs:complexType>
    <xs:sequence>
      <xs:element ref="title"/>
      <xs:element ref="price"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:integer" use="required"/>
  </xs:complexType>
</xs:element>

• Pros: maximum reuse of elements, flat and easy to navigate, elements can be reused by other schemas.
• Cons: every global element can be a valid document root; an element name can only have one definition in the whole schema (a <name> of a person and of a product must share the same type); the element order is harder to follow. Global elements always belong to the target namespace, so a document mixing namespaced and un-namespaced elements is better served by the two other designs (which declare local elements with form="unqualified").

Venetian Blind

Only the root element is global. All complex content models are declared as named types (bookType, addressType…) and elements are declared locally with type="…". Identical structures share one type: two elements with the same content (for instance shipTo and billTo) reuse a single type.

<xs:element name="book" type="bookType"/>
<xs:complexType name="bookType">
  <xs:sequence>
    <xs:element name="title" type="xs:string"/>
    <xs:element name="price" type="xs:decimal"/>
  </xs:sequence>
  <xs:attribute name="id" type="xs:integer" use="required"/>
</xs:complexType>

• Pros: types are reusable and extensible (through xs:extension / xs:restriction), a single global element means a single possible root, namespace exposure of local elements can be controlled with elementFormDefault. This is the design recommended for most real-world schemas.
• Cons: more verbose than the Russian Doll for tiny documents; local elements cannot be reused directly by other schemas (only the types can).

Tips

• Feed the generator a document that is as representative as possible (several records, optional elements present at least once, realistic values): a schema can only describe what was observed.
• A generated XSD is a starting point: add restrictions (enumerations, patterns, lengths), documentation and default values by hand.
• Validate documents against the result with the XML validator (XSD).