All things are permissible, but not all things are beneficial; when developing an XML Schema, this is a good rule of thumb. XML Schema provides many options for developing robust, flexible data structures. One such option is the ability to define nested content model definitions.
All XML elements have a content model. A content model defines the validation rules and structure of an element’s content. Element content can consist of character data, child elements, or a mixture of both. In the cases where an element contains child elements, a content model is used to define the order, cardinality and presence of the child elements. Continue reading
Those of us who have been around since the late 1990s (and even earlier!) remember the promises of XML. It was going to simplify the world by establishing a standard syntax for document interchange between companies and applications, by providing a simple, self-describing tag language that inherently supports nesting of elements and descriptive attributes. Anyone would be able to use this easy-to-understand format to move data in/out of their applications.
Honestly, this notion had serious potential and was viewed as a “disruptive” technology shift. The XML “standard” described how XML documents were structurally composed and even extended the idea to an external document definition using Document Type Definitions (DTDs) and later through the use of XML Schema documents (XSDs) defining the document structure and element data-typing. The standard even provides a method to avoid element name conflicts using a concept called Namespaces. This concept allows a document to use the field “address 1” in multiple contexts, such as Bill-To/Ship-To. As you can imagine, this would be quite useful from a practical implementation standpoint.
The hidden “gotcha” is that XML does not address how a document is used in a business context. Let’s consider a Purchase Order, as an example. Continue reading