Thanks George

I join late this interesting discussion you initiated after our discussion on the problem of the *big* model S1000D+DITA.
The presentation of that problem may give new inputs/thoughts to the discussion.

The case is a model (schema) defining 1850 elements and 650 attributes.
Such a big schema must be designed in a way that makes its writing and maintenance clear and simple.
It must also be designed in a way that eases the testing and makes simple the management of the change of components.
For the interconnection of S1000D and DITA, the result is a set of 148 schemas, all linked together.
A UML representation of this big model has been done : It was the only way to design, define, verify and manage correctly the logic of all the <xs:include>, <xs:redefine> and <xs:import> used in those schemas.

• One challenge was to have each included or imported schema being valid on its own : As Michael Kay has written, we think that it is not humanely acceptable to manage big schemas where included schemas are "partially valid" or "valid only when they are included in including schema" or "valid when used with some instances and invalid for the others". Checking the global validity would be a mess and be probably just impossible to realize.
  
• Since S1000D is the standard for many industries (the entire Aerospace & Defence industries worldwide), it is not possible to propose schemas to this industry which would not be perfectly valid, with no doubt. It is an obligation that the normative committee of S1000D can declare those schemas valid independently from any context. This will be even more true if we propose a big S1000D+DITA model to the industry.
  
• EPWG (S1000D Electronic Publications working Group) must be able to test each component of the S1000D model.
• Flexibility is mandatory and we found that managing libraries of components was the best for that. A group of industries, for the purpose of one project, should easily write a new sub version of the original schema(s).
• Handling recursive inclusions is inevitable and should not be a problem to a parser.

For those interested by this big model, I will provide it on demand.

Regards
Jean-Jacques