As far as I can tell there seem to be four main patterns for drafting a Schema:
One Global Element
This one basically has the root element straight underneath the schema tag, and everything is encapsulated inside it.
- Tends to be quite strict and non-complex for simple documents.
Multiple Global Elements
- Once documents get more complex, it becomes extremely ungainly.
This has everything as a global element, i.e., under the schema tag, and uses references to indicate when elements are nested in others.
- Not strict enough. Gets very messy. There are better ways of doing it.
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.
- Extensible. Easy to encapsulate into another schema.
- Can be a chore sometimes when you need something quick.
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.
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:minLength value="1" />
<xs:minInclusive value="3" />
<xs:minLength value="1" />
<xs:element name="NumOfSides" type="this:SideNumber"/>
<xs:element name="SideLength" type="this:SideLength" minOccurs="3" maxOccurs="unbounded" />
<xs:element name="Name" type="this:ShapeName" />
<xs:element name="NumOfSides" type="this:SideNumber" />
<xs:element name="Sides" type="this:SideInfo" />
<xs:element name="Square" type="this:GeometricShapes" />
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
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.
- Very Strict. Quite extensible, any type can be extended.
- 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
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.
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