Will many of the features in XML Schema be widely used? In particular, I agree that it is better to have an XML language for specifying document layout rather than the DTD language. On the other hand, I am not sure that the document layout should be strongly typed. The nightmare scenario is where a customer cannot place a large order because an XML document is invalid. Assume a company has an average order size of $50,000 dollars with a current order range of $3,000 to $220,000. It would be reasonable to set a criterion in the Purchase Order Schema for this company to set a total order rage of Zero to One Million. At some point in the future, after price increases and business changes, a large customer may place an order for $1,020,000. The Purchase Order document would be rejected as invalid.

Having been involved with Markup since the middle 1980s, I have seen it go through many changes and variations, from GML to SGML to XML. Many specific markup languages such as HTML have been developed. During this time, there has always been a balancing act of content definition vs. content presentation. Most but not all markup languages were defined for presentations purposes. HTML is one of the most widely deployed presentation languages.

Content-only languages are rarer and more specialized. For example, the XML-based languages defined by the RosettaNet effort and many other eCommerce activities are focused on content. In these cases, domain-specific knowledge tends to influence the definition of the markup. For example, a purchase order for the Electronics Parts industry would include information about packaging, environmental limits, and electrical specifications.

On the other hand, a purchase order for the Bulk Chemical industry might include information about purity levels, manufacturing process, and material safety.

It is natural to desire to place validation criteria along with the structure of the documents. For example, if there is a field called Date Required, you would want to make sure it is a valid date. This will ensure that only documents with valid dates are accepted. This leads to document definitions that are very well constrained. From a receiving viewpoint, this is great because it makes sure that all documents are well defined and well organized.

The picture from the sending side is more complex. The sending company may not have a specific date on which the order is required. They may want to say any time in June. There are infinite variations on this. So, do we want to reject entire orders because they cannot meet one specific criterion? It would seem to be better to treat all fields as text, process any orders that meet criteria, and put those that do not in a work queue.

Another concern is that there are limits to what can be validated on an XML document. While it is possible to set dates and such, it would not be reasonable to check for valid product codes, authorization to order, contractual ordering requirements, and so on. Therefore, some of the validation could end up in the XML and some in the back-end processing. A worst-case scenario here is that the validations are inconsistent.

In any complex system, structured data will exist on disk, on a screen or report, in memory as a business object, or in transmission as a business document. Business documents have been verbal, paper, EDI, and most recently, XML. When two cooperating organizations are communicating through business documents, they both need a flexible mechanism to communicate. It seems to me that putting validation in the Schema for an XML document does not allow for this flexibility.