THE XML REVOLUTION - TECHNOLOGIES FOR THE FUTURE WEB

Problems with XML Schema

The general problem:

it is generally too complicated (the spec is several hundred pages in a very technical language), so it is hard to use by non-experts - but many non-experts need schemas to describe data formats
also, the complicated design necessitates an incomprehensible specification style (example from Part 1, Section 3.3.1: "{value constraint} establishes a default or fixed value for an element. If default is specified, and if the element being ·validated· is empty, then the canonical form of the supplied constraint value becomes the [schema normalized value] of the ·validated· element in the post-schema-validation infoset. If fixed is specified, then the element's content must either be empty, in which case fixed behaves as default, or its value must match the supplied constraint value.", or from Section 3.3.4: "If the item cannot be ·strictly assessed·, because neither clause 1.1 nor clause 1.2 above are satisfied, [Definition:] an element information item's schema validity may be laxly assessed if its ·context-determined declaration· is not skip by ·validating· with respect to the ·ur-type definition· as per Element Locally Valid (Type) (§3.3.4).")

Practical limitations of expressibility:

cannot require specific root element (so extra information is required to validate even the simplest documents)
when describing mixed content, the character data cannot be constrained in any way (not even a set of valid characters can be specified)
content and attribute declarations cannot depend on attributes or element context (this was also listed as a central problem of DTD)
- a typical example that cannot be expressed (actually from the XML Schema spec which is packed with examples): "'default' and 'fixed' may not both be present, and [...] if 'ref' is present, then all of <simpleType>, 'form' and 'type' must be absent"
- a solution to this would also eliminate the need for "nil values"
- local definitions allows some degree of context sensitivity, but make it impossible to combine this context sensitivity with e.g. reuse of definitions
it is not 100% self-describing (as a trivial example, see the previous point), even though that was an initial design requirement
defaults cannot be specified separate from the declarations (this makes it hard to make families of schemas that only differ in the default values)
element defaults can only be character data (not containing markup)

Technical problems:

although it technically is namespace conformant, it does not seem to follow the namespace spirit (e.g. "unqualified locals")

The major source of complexity:

the notion of "type" adds an extra layer of confusing complexity:
- in instance documents, we have "elements" which have "element names"
- in schemas, elements are described by "element definitions" which associate "element names" with "type names",
- type definitions associate "type names" with "element descriptions" which describe the elements in the instance documents
(and to cause further confusion, the XML 1.0 spec uses the term "element type" for the name of an element)
xsi:type attributes are required in instance documents when derived types are being used in place of base types
substitution groups and local declarations (with non-unique names) make it difficult to look up the description of a given element

Non-minimalistic design:

the mechanisms for type derivation and substitution groups seem to be different attempts to solve the same problems
incorporation of XPath to express uniqueness and keys (neither uniqueness or keys are fundamental concepts for schemas, so dragging in a big language as XPath seems overkill)
the set of built-in data types is not minimalistic (a minimalistic set + some data type libraries would lower the learning burden)
the use of Perl-style regular expressions violates the principle of using XML syntax to describe XML syntax