XML to XSD

Worked example

<order id="7"><line sku="A">2</line><line sku="B">3</line><note>hi</note></order>

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
  <xs:element name="order">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="line" maxOccurs="unbounded">
          <xs:complexType>
            <xs:simpleContent>
              <xs:extension base="xs:integer">
                <xs:attribute name="sku" type="xs:string" use="required"/>
              </xs:extension>
            </xs:simpleContent>
          </xs:complexType>
        </xs:element>
        <xs:element name="note" type="xs:string"/>
      </xs:sequence>
      <xs:attribute name="id" type="xs:integer" use="required"/>
    </xs:complexType>
  </xs:element>
</xs:schema>

This example is one of XML to XSD's test cases — if the tool stopped producing this output, the build would fail.

Questions

Is the XSD ready to hand to a partner?

Treat it as a first draft. It describes the sample you gave it: an element missing from one parent becomes optional, a repeat becomes maxOccurs="unbounded", and types come from the values present. Tighten it before it becomes a contract.

How are types decided?

From the values themselves — xs:integer, xs:decimal, xs:boolean, xs:date, xs:dateTime, otherwise xs:string. If one element holds 1 in one place and 2.5 in another, the schema widens to xs:decimal rather than guessing.

What about attributes?

Each attribute is declared with its inferred type, and marked use="required" only when it appeared on every instance of that element. A leaf with attributes becomes a simpleContent extension, which is what a hand-written XSD would do.

Namespaces?

Element names are kept exactly as they appear, prefix and all, and the schema is elementFormDefault="qualified". If your sample uses namespaces heavily, add the targetNamespace by hand — inventing one would be a guess.

Related tools