Editing XML Schema (W3C) (section)

==Criticism==
Although XML Schema is successful in that it has been widely adopted and largely achieves what it set out to, it has been the subject of a great deal of severe criticism, perhaps more so than any other W3C Recommendation.
Good summaries of the criticisms are provided by James Clark,<ref>[[James Clark (XML expert)|James Clark]] summary of ''XML Schema'' criticisms, and promotion of [[RELAX NG]] as an alternative, 
https://web.archive.org/web/20150316212413/http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html</ref> Anders Møller and Michael Schwartzbach,<ref>Anders Møller and Michael I. Schwartzbach presents "Problems with XML Schema", http://cs.au.dk/~amoeller/XML/schemas/xmlschema-problems.html</ref> Rick Jelliffe<ref>[[Rick Jelliffe]] critique in May 2009, https://web.archive.org/web/20090516232816/http://broadcast.oreilly.com/2009/05/w3c-please-put-xsd-11-on-hold.html</ref> and David Webber.<ref>[[David Webber (computer scientist)|David Webber]], "[http://www.oasis-open.org/committees/download.php/29164/White%20Paper%20on%20CAM%20and%20XSD.pdf Draft White Paper on CAM v1.1 and XSD Schema V1.1 Insights]", September 1, 2008.</ref>

General problems:
* It is 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. The W3C Recommendation itself is extremely difficult to read. Most users find [http://www.w3.org/TR/xmlschema-0/ W3Cs XML Schema Primer] much easier to understand.
* XSD lacks any formal mathematical specification. (This makes it difficult to reason about schemas, for example to prove that a modification to a schema is backwards compatible.)
* There are many surprises in the language, for example that restriction of elements works differently from restriction of attributes.

Practical limitations of expressibility:
* XSD offers very weak support for unordered content.
* XSD cannot require a 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).
* 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 separately 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").
* XSD 1.0 provided no facilities to state that the value or presence of one attribute is dependent on the values or presence of other attributes (so-called ''co-occurrence constraints''). This has been fixed in XSD 1.1.
* The set of XSD datatypes on offer is highly arbitrary.<ref>
This point is amplified by Uche Ogbuji [http://archive.oreilly.com/pub/post/more_on_xml_class_warfare.html More on XML class warfare - O'Reilly ONLamp Blog]</ref>

* The two tasks of validation and augmentation (adding type information and default values) should be kept separate.