XML schema design patterns

One of the hard things I think about at work is the implications of Data Modelling practices vs XML schema development practices. As an example, there are a lot of folks in the DoD who are enthusiastic about the Command-and-Control Information Exchange Data Model (C2IEDM), a data model developed by the Multilateral Interoperability Programme (MIP).

I have concern that Data Modelling, as a practice, results in good ways to represent information at rest, but that it does not do a good job of developing mechanisms to exchange information. I.e. data modellers define database structures, but do not define languages.

There is a tendency to create good data models, and then run a script to generate the associated XML schema. I worry that this is not sufficient – the resulting XML schema will be good for database replication, but not be useful for anything else.

As an aside, the documentation of the 2002 version of C2IEDM (known as the LC2IEDM) is 315 pages long. The US Air Force, (and others) use a XML schema known as Cursor-on-Target for exchange of C2 data that has 13 elements and can be reasonably documented in about 11 pages. (more here)

C2IEDM and CoT are not pure-competitors; any comparison is not apples-to-apples. In fact, they may be complementary… C2IEDM is a data model, CoT is an XML schema. In other words, CoT can be used to communicate the data that C2IEDM models.

Anyway – most of my concerns are unproven, and understanding the problem will require more thought. I was inspired to blog about this today largely because I stumbled across an article on XML schema: Best Practices called “Global vs Local” that I wanted to link to for future reference that I think has some nuggets that apply to these problems.