DesignPatterns for XmlSchema

As far as I can tell there seem to be four main patterns for drafting a Schema:
* One Global Element
* Multiple Global Elements
* EverythingIsa Type (with the two above variants)
* Semi-ObjectOriented

'''One Global Element'''

This one basically has the root element straight underneath the schema tag, and everything is encapsulated inside it.

Pros:
* Tends to be quite strict and non-complex for simple documents.

Cons:
* Once documents get more complex, it becomes extremely ungainly.

'''Multiple Global Elements'''

This has everything as a global element, i.e., under the schema tag, and uses references to indicate when elements are nested in others.

Pros:
* Very extensible.

Cons:
* Not strict enough. Gets very messy. There are better ways of doing it.

'''EverythingIsa Type'''

This uses the Simple''''''Type and Complex''''''Type tags to death. Basically it specifies every possible element as a type, and builds the structure of the document using those types.

Pros:
* Extensible. Easy to encapsulate into another schema. 

Cons:
* Can be a chore sometimes when you need something quick.

EverythingIsa Type can be merged with the other two patterns although merging types and the Multiple Global Element patterns degenerates into a sticky mess quite quickly.

'''Semi-ObjectOriented'''

This tries to force XmlSchema into an ObjectOrientedProgrammingLanguage, even though XmlSchema is not a ProgrammingLanguage nor is it ObjectOriented. It uses the basic extension and restriction of types as a basis for everything.

''Can you elaborate on what you mean by "force XmlSchema into an ObjectOrientedProgrammingLanguage''?

A simple example (although slightly biased because it uses the common Shape idea) would be:

        <xs:simpleType name="Shape''''''Name">
		<xs:restriction base="xs:string">
			<xs:minLength value="1" />
		</xs:restriction>
	</xs:simpleType>
	
	<xs:simpleType name="Side''''''Number">
		<xs:restriction base="xs:positiveInteger">
			<xs:minInclusive value="3" />
		</xs:restriction>
	</xs:simpleType>
	
	<xs:simpleType name="Side''''''Length">
		<xs:restriction base="xs:positiveInteger">
			<xs:minLength value="1" />
		</xs:restriction>
	</xs:simpleType>
	
	<xs:complexType name="Side''''''Info">
		<xs:sequence>
			<xs:element name="NumOfS''''''ides" type="this:Side''''''Number"/>
			<xs:element name="Side''''''Length" type="this:Side''''''Length" minOccurs="3" maxOccurs="unbounded" />
		</xs:sequence>
	</xs:complexType>
	
	<xs:complexType name="Shapes">
		<xs:choice>
			<xs:element name="Name" type="this:Shape''''''Name" />
		</xs:choice>
	</xs:complexType>
	
	<xs:complexType name="Geometric''''''Shapes">
		<xs:complexContent>
			<xs:extension base="this:Shapes">
				<xs:choice>
					<xs:element name="NumOfS''''''ides" type="this:Side''''''Number" />
					<xs:element name="Sides" type="this:Side''''''Info" />
				</xs:choice>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
	
	<xs:element name="Square" type="this:Geometric''''''Shapes" />
It just seems like an awful lot of work for one element. Granted, you can basically specify any type of shape throughout your schema, But it really seems like overkill to me. And I'm sure you can see why it seems difficult to implement. I would say that the biggest problem of this approach is that it's used when it's not necessary, hence complicating the schema.

Furthermore, the example above only uses basic restriction and extension to enforce data rules; there are other OO-like operations that can be performed, such as <xs:union> (Composition), <xs:redefine> (Overriding) and <xs:substituteGroup> (Polymorphism). The OO concepts that I placed in brackets aren't what the designers of XmlSchema intended, but for the average programmer today, who we may assume has only ever been in contact with fully OO languages (notable exception of CeePlusPlus and ScriptingLanguage''''''s), these concepts spring all too easily to mind. Hence they tend to try to use it as a ProgrammingLanguage, when it's not.

''to head off the LanguagePissingMatch, by fully OO languages I meant only OO is supported, not functional, etc. as well.''

By staying true to their programming training (not a bad thing) they force OO-ness when they misperceive the functions of certain features. The same can be said for any non-OO language I guess, where programmers still think in an OO style, but the form of expression they're using doesn't support it fully. This tends to lead to good design expressed very badly.

Pros:
* Very Strict. Quite extensible, any type can be extended.

Cons:
* Very obfuscated mechanisms for extending inherited types. Tends to be difficult to implement.

Personally, my preference is between a mixture of the EverythingIsa Type approach, the One Global Element, and the Semi-ObjectOriented approaches. 

This seems to produce a schema that is extensible, yet not too loose to allow silly errors to go through. Using the OO abilities, you can force the XML data to match specific patterns, then use those patterns throughout your types which define your non elementary elements.

I do however think that XmlSchema is usually not understood properly, or perhaps seen as overly complex. It does look quite daunting at first and the W3C documentation is even more complex.

-- RonaldHobbs

----

Two of these patterns sound like patterns that can be found at http://www.xmlpatterns.com/

The One Global Element patterns seems like http://www.xmlpatterns.com/UniversalRootMain.shtml and Multiple Global Elements patterns seems like http://www.xmlpatterns.com/MultiRootDTDMain.shtml
----
CategoryXml CategoryPattern